AD-A228  467 


m  FILE  COpY 


Repository  Prototype 
System  Specification 


Document  Number  CDRL  1590 

February  16,  1990 


Prepared  for: 

Electronic  Systems  Division  (PKG-1) 
Air  Force  Systems  Command,  USAF 
Hanscom  AFB ,  MA  01731-5000 


Prepared  by: 

IBM  Systems  Integration  Division 
18100  Frederick  Pike 
Gaithersburg,  MD  20879 


i 


1.  AGENCY  USE  ONLY  (leave  Blank!  2.  REPORT  OATE 

February  16,  1990 


A  TITLE  and  subtitle 

Repository  Prototype  System  Specification 


i  REPORT  TY<-t  AND  DATE;  COVERED 

Final 


j  i  I  UN  DING  NUMBERS 

j  C:  F19628-88-D-0032 


0.  AUTHOR(S) 

l 

1 

T.  Ward 

i 

j 

7.  PERFORMING  ORGANIZATION  MAME(S)  AND  ADDKFSS(ES) 

6.  PEI.' CAM  NO  ORGANIZATION 

REPORT  NUMBER  I 

IBM  Federal  Sector  Division 

800  N.  Frederick  Avenue 

Gaithersburg,  MD  20879 

! 

i 

9.  SPONSORING MONITORING  AGENCY  NAMEtS)  AND  ADDKLSS(CS) 

10.  SPONSORING  '  MONITORING  j 

AGENCY  REPORT  NUMBER  i 

Electronic  Systems  Division 
■  Air  Force  Systems  Command,  USAF 

Hanscom  AFB ,  MA  01731-5000 

_ 

| 

CDRL  Sequence  No.  1590  | 

i 

n.  supplementary  notes 

12a.  DISTRIBUTION  AVAILABILITY  STATEMENT 

1 

; 

Ub.  DISTRIBUTION  CODE 

1  13.  ABSTRACT  (Maximum  200  words) 


i 

\  A  specification  of  the  capabilities,  characteristics  and  tools  for  a  software  reuse  j 
|librarv.  Defines  the  minimum  set  of  integrated  software  development  and  data  process-! 
j  ing  facilities  needed  to  maintain  and  support  a  software  reuse  library.  J 


t 

) 


|  14  SUBJECT  TERMS 

|  STARS,  software  reuse,  software  reuse  library 

| 

IS.  NUMBER  OF  PAGES 

89 

16.  PRICE  CODE 

j  17.  SECURITY  CLASSIFICATION 

18  SECURITY  CLASSIFICATION 

19.  SECURITY  Cl ASSli  ICATION 

2’J.  LIMITATION  OF  ABSTRACT 

j  OF  REPORT 

OF  THIS  PAGE 

OF  ABSTRACT 

j  Unclassified 

Unclassif ied 

Unclassified 

UL 

7  >‘‘J)  0  ’  -u 


ABSTRACT 


This  Technical  Report  (CDRL  Seq.  No.  1590)  addresses  Subtask  IR40.2 
(Prototype  Repository  System)  of  the  STARS  Delivery  Order  Task  IR40  (Re¬ 
pository  Integration).  Included  in  the  appendices  are  the  Repository 
System  Specifications  developed  over  the  first  two  Increments  (Q  and  R) 
of  the  STARS  Competing  Primes  Contract.  These  specifications  also  contain 
items  projected  for  S-Increment  development  and  evaluation. 

The  contents  of  this  document  contain  lessons  learned  from  building  and 
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modifications  to  the  repository  and  repository  environment,  and  other 
accomplishments  (as  required  by  DI-S-3591/A) . 
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•  DI-MCCR-80025A  Software  Requirements  Specification  (A010) 
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1.0  INTRODUCTION 


1.1  IDENTIFICATION 


This  document,  Repository  Prototype  System  Specifications  (CDRL  1590), 
contains  lessons  learned  and  specifications  for  an  improved  repository 
prototype  (Subtask  IR40 . 2  of  Delivery  Order  Task  IR40  for  IBM  Contract 
Number  F19628-88-D-0032) . 


1.2 
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This'mWtf.  documents  the  lessons  learned  while  developing  and  using  the 
IBM  Team  STARS  Repository  System.  It  also  provides  rationale  for  limited 
changes  and  specifications  for  an  improved  repository  prototype  based  on 
experience  with  previous  versions  of  the  STARS  Repository  Prototype. 
Increment  1  and  2  prototyping  efforts  have  provided  a  capability  to  study 
and  evaluate  methods  for  collecting,  searching,  and  accessing  reusable 
information,  e.g. ,  software  and  documents  stored  in  and  retrieved  from  a 
classical,  hierarchical  taxonomy  based  structure.  In  addition,  informa¬ 
tion  stored  and  retrieved  by  more  user-friendly  methods  (e.g.,  sets  of 
related  attributes  (or  facets)  defined  when  reusable  component  parts  are 
added  to  the  repository)  were  prototyped  and  evaluated.  Each  method  was 
used  independently  and  in  combination  with  other  methods. 


1.3  PURPOSE 


This  document  establishes  an  initial  set  of  specifications  for  future 
evolution  of  the  IBM  Team  STARS  Repository  System  to  an  improved  reposi¬ 
tory  system  for  the  STARS  program  and  eventual  release  to  other  DoD  or 
commercial  programs.  The  specifications  contained  in  the  appendices  are 
based  on  the  lessons  learned  and  the  growing  set  of  information  that  is 
contained  in  the  referenced  documents  and  include  the  following: 

•  Repository  System  Requirements  Specifications 

•  Repository  Top  Level  Design 

•  Repository  Database  Detain  Design 

The  specifications  and  designs  do  not  reflect  the  current  state  of  the 
IBM  Team  STARS  Repository.  The  current  implementation  and  capabilities 
as  well  as  the  concepts  and  guidelines  related  to  the  current  system  are 
contained  in  the  referenced  items,  i.e.,  CDRL  1540,  1570,  1580,  and  1600 
(Releases  A,  B,  C,  and  D). 


Introduction 


1 


2.0  REFERENCED 
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Repository  Guidebook  (Draft),  dated  January  31,  1990 
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Filter  Prototype,  dated  January  24,  1990  (and  earlier 
releases  A,  B,  and  C) 
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Taxonomy/Classification,  dated  January  19,  1990 


IBM  CDRL  1600 


Repository  Prototype,  Release  A,  dated  July  15,  1989 
(and  subsequent  releases  B,  C,  and  D) 


2.2  NON-GOVERNMENT  DOCUMENTS 
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3.0  TECHNICAL  WORK  ACCOMPLISHED 


The  initial  repository  prototyping  effort  was  accomplished  in  the  first 
increment  of  the  STARS  Program  and  the  basic  capabilities  were  demon¬ 
strated  on  a  workstation,  i.e.,  an  IBM  PC  AT  (DOS).  Four  releases  of  the 
second  increment  prototypes  were  developed  and  demonstrated  on  a  large 
host,  i.e.,  a  DEC  VAX  (VMS).  The  first  increment  workstation  prototype 
was  rehosted  on  the  larger  system  with  a  minimum  effort.  The  only  major 
problem  was  that  the  Ada/SQL  Bindings  for  the  two  systems  were  different 
and  required  changes  to  the  logic  that  maps  the  data  fields  in  the  data¬ 
base  to  Ada  variables.  Minor  changes  were  also  required  in  the  STARS 
virtual  interfaces  defined  to  support  portability  objectives. 

The  reuse  of  existing  code  presented  another  problem  when  the  reused  code 
required  modification  and  the  reused  code  was  the  responsibility  of  other 
tasks  and  organizations.  Multiple  versions  had  to  be  maintained  until  the 
modified  versions  were  approved  and  maintained  as  reusable  components. 
This  process  resulted  in  the  improvement  of  reusable  components  but  did 
result  in  delays  in  the  delivery  of  specific  repository  capabilities. 

All  search  and  access  capabilities  planned  for  the  R-Increment  releases 
(i.e.,  CDRL  1600A,  B,  C,  and  D)  of  the  repository  prototype  were  accom¬ 
plished  including: 

•  Porting  to  and  integration  with  new  host  environment 

•  First  Increment  problems  and  limitations  were  removed 

•  Multiple- level  Hierarchical  Search  Criteria  was  added 

•  Inclusion  of  a  Catalog  generation  and  browsing  feature 

•  Development  of  a  Component  Supply/Filtering  mechanism 

•  Maintenance  of  user,  organization,  and  contract  information 

•  Component  Copy/Component  Part  Copy  with  usage  statistics 

•  Component  Subscriptions  and  Report  Distribution  support 

•  Integrated  Component  Problem  &  Component/Part  Change  Reports 

•  Testing  of  prototype  on  Virtual  Operating  System  Interface 

The  implementation  and  use  of  the  prototype  during  this  increment  was  used 
to  define  the  specifications  contained  in  this  document.  Specific  lessons 
learned  will  be  covered  in  "information  Gained  from  the  Performance"  on 
page  9  and  referenced  to  specific  sections  of  the  specifications.  The 
following  paragraphs  will  define  the  terms  used  in  this  document  and  de¬ 
scribe  the  major  concepts,  objectives,  and  capabilities  included  in  re¬ 
pository  prototyping  effort. 


3.1  DEFINITION  OF  TERMS 


The  following  terms  are  used  in  this  document  and  are  consistent  with  the 
same  terms  used  in  other  documents  delivered  in  IQ12  and  IR40.  The  fol¬ 
lowing  subparagraphs  relate  the  key  terms  to  either  repository  system 
concepts  or  operational  concepts. 
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3.1.1  SYSTEM  CONCEPTS 


Repository  System 

An  instance  of  the  software  engineering  environment,  including  com¬ 
puter  hardware,  software  tools  and  environment,  standards  and  pro¬ 
cedures,  that  together  provide  a  complete  repository  capability. 

Repository 

An  elem  nt  of  the  software  engineering  environment  that  is  used  to 
store  reusable  items,  e.g.,  software  work  products,  and  information 
describing  the  items,  e.g.,  the  author  and  owner.  The  reusable  data 
within  the  Repository  is  referred  to  as  repository  contents. 

Library 

A  collection  of  reusable  components  that  require  special  handling, 
e.g.,  access  control,  higher  level  security,  privacy  requirements, 
or  limited  access  during  specific  software  development  phases. 

Software  Work  Product/ Information 

An  intermediate  or  finished  work  product  of  software  development  or 
maintenance.  Software  work  products  include  plans,  specifications, 
designs,  source  and  object  code,  test  procedures,  reports,  demon¬ 
strations  and  other  reusable  items  of  information. 

Component 

A  collection  of  related  work  products  that  are  intended  to  be  used 
as  a  consistent  set  of  information,  e.g.,  Documents,  Software  Pro¬ 
grams,  Project  Plans,  and  other  types  or  forms  of  reusable  Informa¬ 
tion.  Regardless  of  the  type  or  form,  a  collection  of  reusable 
information  is  always  referred  to  as  Component  in  this  document. 

Component  Part 

A  retrievable  element  of  a  component  (e.g.,  requirement  and  design 
specifications,  software  source  code  or  processed  forms  of  that 
code,  a  formal  document  outline,  minutes  from  a  project  review 
meeting,  etc.).  Individual  repository  operations  are  performed  on 
these  elements,  e.g.,  Browse,  Copy,  and  counting  the  total  number 
of  retrievals.  This  document  refers  to  these  elements  as  Parts. 

Variations 

Specific  occurrences  of  similar  Components  or  Component  Parts  that 
contain  equivalent  or  near  equivalent  information  or  function.  Each 
variation  may  have  a  separate  author,  a  different  owner,  different 
set  of  data  rights,  etc.  and  variations  are  required  to  be  stored 
under  unique  names.  Unique  names  are  not  required  if  a  unique 
identifier  number  is  also  assigned  as  defined  in  the  Data  Dictionary 
("Data  Dictionary"  on  page  62). 

Versions 

Specific  occurrences  of  Components  or  Component  Parts  except  that 
they  are  incremental  updates  of  the  same  named  object.  They  may  have 
a  different  repository  entry  date,  added  or  corrected  information 
or  function,  new  or  modified  restrictions  to  its  use,  etc.  Versions 
are  required  to  be  stored  under  the  same  unique  name. 
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Component/Part  Owner 

The  Repository  user  who  had  the  responsibility  to  create  (or  has  the 
responsibility  to  maintain)  a  specific  Repository  (Variation  or 
Version)  Component  or  Component  Part,  i.e.,  Repository  image  of  the 
corresponding  reusable  item. 

Repository  System  Problem  Report 

An  on-line  report  generated  by  any  valid  STARS  Repository  user  that 
the  user  believes  applies  to  the  Repository  System  as  a  whole.  A 
response  report,  generated  by  an  authorized  user,  may  be  attached. 

Repository  Component  Problem  Report 

An  on-line  report  generated  by  any  valid  STARS  Repository  user  that 
the  user  believes  applies  to  a  specific  Component  version.  A  re¬ 
sponse  report,  generated  by  the  Component  owner  or  another  author¬ 
ized  user,  may  be  attached. 

Repository  Component/Part  Change  Report 

An  on-line  report  generated  by  the  owner  or  another  Repository  user 
assigned  responsibility  for  a  particular  Component  version  or  Com¬ 
ponent  Part  Version.  The  report  explains  the  changes  made  and  should 
be  supplied  and  processed  for  acceptance  with  the  new  version. 


3.1.2  OPERATIONAL  CONCEPTS 


Component/Part  Supply 

The  process  by  which  the  Repository  content  is  established,  i.e., 
the  acquisition  and  installation  (for  authorized  user  access). 

Component/Part  Management 

The  process  by  which  the  Repository  content  is  maintained,  tracked, 
distributed,  archived,  and  deleted.  This  process  is  affected  by  cost 
of  the  process  and  the  availability  of  funds  as  well  s  by  the  in¬ 
dividual  data  rights,  risks,  and  responsibilities  assigned  to  spe¬ 
cific  individuals  or  organizations.  This  could  involve  the 
collection  and/or  distribution  of  fees  associated  with  the  Compo¬ 
nents  or  specific  Component  Parts,  i.e.,  if  items  associated  with 
fees  are  to  be  stored  in  the  STARS  Repository. 

Repository  Supplier 

Any  individual  or  organization  that  supplies  data  to  the  Repository, 
e.g.,  authors,  owners,  and  distributors  of  Software  Work  Products 
or  information  related  to  individual  products,  e.g.,  Problem  Re¬ 
ports.  Included  in  this  definition  are  individuals  or  organizations 
responsible  for  the  testing,  verification,  validation,  certif¬ 
ication,  maintenance,  or  any  other  task  where  responsibility  has 
been  assigned  for  a  task  related  to  Repository  content  maintenance. 

Repository  Managers/Librarians/Administrators 

Individuals  or  organizations  that  are  responsible  for  the  operation 
and  maintenance  of  the  Repository  System.  Included  in  this  defi¬ 
nition  are  individuals  or  organizations  responsible  for  the  testing, 
verification,  validation,  certification,  maintenance,  or  any  other 
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defined  task,  i.e.,  where  responsibility  has  been  explicitly  as¬ 
signed  for  a  task  related  to  Repository  System  maintenance. 

Repository  Subscribers/Re-users 

Individuals  or  organizations  that  use  the  contents  of  the  Repository 
including  Software  Products  and  information  acquired  by  direct  on¬ 
line  examination,  by  copy  commands,  or  by  other  method  of  retrieval 
from  the  Repository. 

Repository  Gatekeeper/Filtering 

The  process  by  which  the  repository  contents  are  controlled,  i.e., 
admission  or  removal  of  Components,  Component  Parts,  and  related 
Reports.  This  process  is  based  of  predefined  qualification  criteria 
but  can  be  a  manual  process  and/or  by  automated  tools.  The  process 
controls  both  the  quality  and  integrity  of  the  repository  contents, 
i.e..  Components,  Components,  Component  Versions,  Component  Parts, 
Component  Part  Versions,  Component  or  Component  Part  Change  Reports, 
and  Component  Problem  Reports. 

Qualification 

The  act  of  establishing  that  a  Component  and  its  Component  Parts  meet 
the  necessary  criteria  for  admission  into  the  STARS  Repository, 
i.e.,  making  the  information  available  for  on-line  access  and/or 
distribution. 

Disqualification 

The  act  of  establishing  that  a  software  work  product  does  not  meet 
necessary  criteria  for  storage  on  the  STARS  Repository  or  meets 
criteria  for  removal  from  an  accessible  state  after  residing  on  the 
Repository. 

Migration 

The  act  of  moving  Components  or  Component  Parts  from  one  library  to 
another  or  the  act  of  promoting  or  demoting  Components  and  Component 
Parts  from  one  state  to  another  within  a  single  library,  e.g.,  from 
a  non-validated  state  to  an  independently  validated  state. 

Authorization 

The  transfer  or  assignment  of  rights  to  individual  users  for  specific 
repository  operations,  repository  system  or  content  maintenance,  or 
the  examination  and  use  of  the  repository  contents  or  related  in¬ 
formation. 

Distribution 

The  electronic  transfer  or  shipment  of  other  media  containing  work 
products  (e.g.,  Reports,  Components  or  Component  Parts)  or  other 
types  of  information  from  the  STARS  Repository  to  authorized  users 
or  to  the  user's  organization. 

Main  Menu  Screen 

The  initial  screen  presented  to  users  by  the  STARS  Repository  System, 
e.g.,  the  user  enters  "REPOS"  at  the  VMS  command  prompt(S).  This 
screen  presents  a  set  of  (user)  selectable  options,  e.g.,  Component 
Search.  Each  option  initiates  specific  STARS  System  processing  or 
lower  level  menu  selection  screens. 
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Component  Search  Screens 

A  set  of  screens  associated  with  Search  and  Access  processing,  e.g., 
a  screen  to  select  the  search  method  desired  by  the  user.  The 
screens,  or  window  overlays  used  in  the  repository  prototype,  allow 
a  user  to  specify  search  criteria  and  browse  information  related  to 
individual  components  selected  by  the  user's  search  criteria. 
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4.0  INFORMATION  GAINED  FROM  THE  PERFORMANCE 


The  following  paragraphs  describe  the  lessons  learned  in  the  performance 
of  subtasks  of  Task  IR40.  The  following  list  summarizes  the  major  lessons 
learned  by  major  paragraph  heading  where  detail  is  presented.  Some  of  the 
items  are  unique  to  a  repository  system  where  multiple  users  and  terminal 
are  supported  or  to  systems  where  a  simple,  rapid  response  interface  is 
required . 

•  Repository  System  Capabilities 

—  An  immature,  untested  Repository  System  will  discourage  users. 

-  System  problem  and  problem  correction  reports  encourage  users. 

-  Slow  or  unreliable  communication  links  will  discourage  users. 

—  High-speed  links  or  distributed  capabilities  encourage  users. 

—  Forums  are  good  for  new  users  but  can  be  very  time  consuming. 

—  Integrated  and  tested  Repository  System  tools  save  user-time. 

-  Repository  System  tools  have  to  be  maintained  and  improved. 

•  Repository  Capabilities 

—  Immature,  untested  Repository  components  will  discourage  users. 

—  Component  problem  and  problem  correction  reports  encourage  users. 

-  Validated  components  and  integrated  information  save  user-time. 

-  A  single  classification  and  search  method  does  not  satisfy  users. 

-  Repository  capabilities  will  have  to  be  maintained  and  improved. 

-  Component  standards  and  supply  filtering  is  a  continuous  expense. 

-  Component  storage  and  distribution  methods  continue  to  evolve. 

•  User  Interface 

-  A  consistent,  simple  interface  is  critical  and  saves  user-time. 

-  A  repository  interface  must  match  the  user's  terminal  interface. 

-  Screen  layouts  can  impact  users  not  familiar  with  the  standard. 

-  Simple  commands  are  better  than  specific  terminal  key  assign¬ 
ments  . 

-  Limited  training  is  required  for  complex  information  searches. 

-  Fast  command  selection  and  exit  from  nested  screens  are  required. 

•  Database 

-  Custom  screen  generation  is  faster  than  with  commercial  tools. 

—  Custom  screen  generation  provides  consistent  commands  and  for¬ 

mats  . 

—  Duplicate  component  and  part  names  require  a  unique  index  field. 

—  Search  criteria  and  screen  content  require  multiple  table  joins. 

-  Correct  information  about  users  and  organizations  is  important. 


4.1  REPOSITORY  SYSTEM  CAPABILITIES 


The  concepts  and  scope  established  by  the  Request  for  Proposal 
(F19628-88-0011)  and  direction  and  concepts  defined  in  subsequent  deliv¬ 
erables  (e.g.,  CDRLs  460  and  470)  are  to  be  integrated  in  a  Software  En¬ 
gineering  Environment  (SEE).  This  includes  the  possibility  of 
distributing  the  repository  capability  to  individual  DoD  and  commercial 
programs  as  either  a  stand-alone  operation  or  as  a  cooperating  node  in  a 
distributed  network  of  Software  Development  Environments.  Program  Man¬ 
agement,  Configuration  Management,  and  the  development  and  reuse  tools 
require  a  common  user  interface  and  the  same  database  or  a  standard 
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interface  to  multiple  databases  to  be  integrated  in  a  SEE.  The  repository 
prototyping  efforts  to  date  examined  the  STARS  Repository  System  re¬ 
quirements  (CDRLs  0470,  0500,  and  0520)  as  they  apply  to  developing, 
maintaining,  locating,  and  distributing  reusable  components. 


4.1.1  COMPONENTS  AND  COMPONENT  MAINTENANCE 


When  a  repository  is  populated  with  immature  components  then  the  users 
are  less  likely  to  select  the  components  for  reuse  in  software  involving 
mission  or  project  critical  development  efforts.  This  is  offset  somewhat 
if  the  user  knows  the  components  are  actively  being  improved  or  are  also 
critical  to  projects  responsible  for  maturing  the  reusable  components. 
If  problem  report  generation,  problem  tracking,  and  component  maintenance 
contracts  are  in  place  to  correct  the  problems,  then  users  may  choose  to 
start  prototyping  or  implementing  with  the  repository  contents.  Adequate, 
reliable  problem  tracking,  problem  closure  tracking,  and  Configuration 
Control  (CDRL  0520)  capabilities  are  required  to  give  the  users  confidence 
in  any  repository. 

A  Problem  Reporting  capability  was  developed  and  integrated  with  the  STARS 
Repository  Prototype  to  better  understand  reuse  in  the  context  of  a  total 
SEE  environment  ("Problem  Report  Options"  on  page  44).  This  capability 
allows  the  user  to  immediately  view  all  reports  relating  to  the  specific 
version  of  the  component,  to  generate  a  new  Problem  Report,  or  to  generate 
a  response  to  Problem  Reports  assigned  to  the  user  ("Report  Operations 
Selection  Screen"  on  page  42) .  The  user  can  also  examime  Change  Reports 
relating  to  specific  Component  versions  ("Problem  Reports  for  Selected 
Component"  on  page  43)  or  to  specific  Part  versions  (  "Changes  to  selected 
Part  Version"  on  page  53).  If  the  user  first  lists  all  versions  of  a 
component  ("Versions  of  a  Selected  Component"  on  page  40)  or  all  versions 
of  a  part  ("Version  of  selected  part"  on  page  51)  then  the  user  is  able 
to  examine  reports  in  any  version/time  sequence. 

The  integration  of  reports  into  the  Search  and  Access  process  is  very 
efficient  from  a  user's  standpoint  and  provides  the  information  that  a 
user  requires  to  make  appropriate  initial  selections  or  subsequent  re¬ 
placement  of  previously  selected  components. 


4.1.2  INFORMATION  AND  INFORMATION  EXCHANGE 


Forums  and  individual-to-individual  communication  are  good  in  some  ways 
but  totally  inadequate  for  very  large  repositories.  Information  about 
all  components  should  not  be  automatically  sent  to  individual  users  nor 
should  one  expect  users  to  browse  forums,  no  matter  how  well  organized. 
Forums  are  good  for  informal  communication  but  not  for  timely  exchanges. 

Users  should  be  requested  to  Subscribe  to  specific  components  that  are 
being  used  or  are  being  considered  for  use.  Information  about  components, 
e.g. ,  problem  or  change  reports,  should  be  linked  to  the  specific  library 
and  component  part  version  to  which  it  applies.  This  approach  was  proto¬ 
typed  along  with  the  Search  and  Access  capabilities  in  order  that  the  user 
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need  onT  receive  reports  related  to  the  choice  of  particular  components. 
The  capability  allows  users  to  browse  reports  on-line  and  to  subscribe, 
to  un-subscribe,  or  to  view  the  user's  list  of  current  Component  sub¬ 
scriptions  ("User  Subscription  Options"  on  page  48). 


4.2  REPOSITORY  CAPABILITIES 


An  objective  of  the  STARS  Program  was  to  prototype  and  evolve  a  SEE  and 
a  repository  system  to  a  level  where  reuse  technology  could  be  studied, 
evolved,  and  sufficiently  matured  to  move  the  technology  into  practice. 
At  the  time  of  the  original  RFP  and  as  stated  in  the  RFP,  it  was  clear 
that  a  single  hierarchical  classification  methods  was  not  sufficient  to 
satisfy  all  repository  requirements.  During  the  first  two  increments  of 
the  STARS  Program  multiple  classification  and  retrieval  schemes  have  been 
prototyped  and  studied.  The  success  of  any  method  or  combination  of 
methods  depends  on  the  understanding  of  both  the  individual  doing  the 
classifying  and  the  user  involved  with  the  search  and  access. 

A  conclusion  that  can  be  drawn  from  user  experience  with  the  prototype 
repository  is  to  let  a  user  select  from  a  set  of  methods  and  hide  the 
details  of  the  other  methods  from  that  user  ("Component  Type  Selection 
Screen"  on  page  32).  The  repository  prototypes  (that  have  been  developed 
and  used)  merge  the  search  methods  into  a  single  screen.  This  technique 
is  still  valid  if  a  user  chooses  to  use  a  combination  of  methods  in  a 
single  search  operation,  i.e.,  a  single  summary  screen.  The  previously 
entered  search  criteria  is  displayed  for  the  user  to  modify,  select,  or 
de-select  specific  search  parameters  without  re-entering  the  entire  set 
of  search  criteria  ("STARS  Repository  Search  Criteria  Summary"  on  page 
38)  . 

For  a  very  large  repository,  covering  many  application  domains,  Facet  and 
Facet  Term  lists  may  get  very  lengthy.  The  set  of  terms  and  aliases  will 
grow  as  the  repository  contents  grow  to  cover  other  domains;  in  fact  there 
may  come  a  point  where  the  terminology  is  not  consistent  across  domains. 
One  solution  is  to  have  a  hierarchy  of  search  criteria  selection,  e.g., 
component  type  or  application.  Multiple  component  types  are  supported  by 
the  Repository  Prototype  and  the  set  of  attributes  used  to  make  the  se¬ 
lection  varies  by  component  type.  This  technique  may  prove  useful  for 
the  other  search  methods,  e.g.,  facets  or  hierarchical  classifications. 


4.2.1  REPOSITORY  SYSTEM  MAINTENANCE  AND  OPERATION 


It  is  important  to  designate  a  specific  budget  for  the  maintenance  of  the 
existing  capabilities  in  addition  to  the  budget  required  to  operate  the 
repository  on  a  day-to-day  basis.  This  is  particularly  important  for  the 
first  year  of  operation  after  the  repository  is  made  available  to  a  wider 
set  of  users,  i.e.,  the  first  few  months  of  heavy  access  will  discover 
errors  and  performance  problems  not  detected  in  system  test.  This  budget 
can  cover  commercial  product  upgrades  and  regression  testing.  In  addi¬ 
tion,  a  budget  should  be  available  to  automate  labor  intensive  operations 
that  were  also  not  discovered  in  time  tc  provide  automated  capabilities. 
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e.g.,  in  the  component  supply  or  distribution  process.  This  budget  can 
cover  responding  to  Repository  System  Problem  Reports  and  general  support 
to  new  users  of  the  STARS  Repository  System. 

The  prototype  repository  (CDRL  1600)  has  several  manual  operations  sup¬ 
ported  by  on-line  input  forms  ("STARS  Repository  Registration  Forms"  on 
page  57)  that  simplify  the  maintenance,  i.e.,  the  maintainer  does  not  have 
to  know  the  SQL  interface  to  the  commercial  RDBMS  used  to  support  the 
repository.  Access  to  the  forms  are  restricted  to  authorized  individuals, 
i.e.,  any  user  should  not  be  able  to  determine  information  about  any  other 
user . 


4.2.2  CONTENT  MAINTENANCE  AND  DISTRIBUTION  PROCESS 


To  support  the  Component  Problem  Reports  requires  the  authority  to  make 
changes  to  specific  Components  and  Component  Parts.  This  authority  may 
not  be  centralized  and  may  require  the  re-assignment  of  Problem  Reports 
to  other  registered  users  of  the  STARS  Repository  (Figure  22  on  page 
45). 


4.2.3  COMPONENT  SUPPLY  AND  FILTERING  PROCESS 


A  major  problem  encountered  with  any  large  repository  of  information  is 
diverse  styles,  content,  and  quality  of  the  information.  This  will  be  a 
significant  problem  with  the  STARS  Repository  when  reusable  components 
are  collected  from  various  contract  deliverables  or  imported  from  other 
repositories.  For  example,  contracts  issued  by  the  different  Government 
agencies  (USAF,  Navy,  Army,  NASA,  FAA,  etc.)  specify  a  different  set  of 
standards  to  be  used  in  the  generation  and  delivery  of  the  contract  end 
items  (CDRLs).  The  differences  in  many  cases  may  not  be  significant  but 
some  preprocessing  of  the  component  parts  may  be  required  to  achieve  a 
level  of  consistency  across  the  repository  contents.  This  approach  is 
certainly  beneficial  to  potential  re-users  of  the  information. 

The  STARS  Repository  will  require  at  least  a  minimum  level  of  consistency 
of  the  information  provided  by  the  Component  Suppliers.  This  includes 
electronic  data  transfer  standards  for  specific  media.  These  standards 
will  evolve  with  the  related  technologies  and  with  the  set  of  potential 
suppliers.  Acceptable  variations  in  information  format,  content,  and 
media  should  be  documented  in  the  STARS  Operation  and  Procedures  (see  CDRL 
1470  for  an  example)  and  in  User's  Guidebooks  (CDRL  1550).  A  single 
standard  that  is  used  by  all  developers  and  suppliers  will  not  be  achieved 
in  the  near  future,  therefore  a  filtering  and/or  correction  process  is 
the  only  way  to  achieve  the  desired  results  in  the  near  term. 

For  all  software  components,  including  the  associated  documentation,  the 
following  automated  or  manual  processing  is  considered  the  minimum  eifo.  t 
that  should  be  performed  on  components  supplied  to  the  repository.  In  the 
case  of  the  compilation  and  test  case  execution,  it  is  assumed  that  the 
processing  is  either  accomplished  by  the  supplier  or  the  STARS  Repository 
users,  i.e.,  either  the  repository  suppliers  or  management  personnel.  The 
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component  parts  should  include  test  code  or  data  sufficient  to  establish 
the  correctness  of  the  reusable  source  code,  even  if  the  component  is  not 
a  complete  compilation  units,  e.g.,  code  fragment  or  template. 

•  Component  compilation,  execution  module  builds,  and  execution 

•  Computation  of  various  metrics,  e.g.,  complexity,  re-usability 

•  Quality  checks,  e.g.,  completeness,  style,  clarity,  correctness 

•  Security  checks,  e.g.,  ownership,  copyrights,  viruses,  etc. 


4.2.4  REUSE  AND  DEVELOPMENT  PROCESS 


The  capabilities  of  the  prototype  repository  were  developed  to  support 
reusable  components  that  range  in  size  and  scope  from  fragments  to  very 
large  reusable  systems,  e.g.,  a  Software  Development  Environment  (SDE) 
or  an  aircraft  guidance,  navigation,  and  control  system.  Reusable  com¬ 
ponents  can  be  either  generic  or  developed  for  a  specific  application. 
The  components  could  have  been  developed  with  reuse  in  mind  or  be  recov¬ 
ered  from  delivered  work  products,  e.g.,  technical  reports,  formal  docu¬ 
ments,  and  programming  or  design  language  code.  Even  if  the  work  products 
were  not  designed  with  reuse  in  mind,  there  may  be  small  or  large  portions 
that  are  reusable  with  little  work  required  to  extract  the  information 
required  by  the  STARS  Repository  System  (see  "STARS  Repository  Registra¬ 
tion  Forms"  on  page  57  and  CDRL  1460). 

To  support  the  reuse  of  large  systems  or  subsystems,  a  capability  was 
prototyped  to  allow  the  break-up  of  the  large  reusable  components  into 
smaller  reusable  components  or  to  allow  the  systematic  build-up  of  large 
reusable  components  from  existing  reusable  components.  The  smaller  re¬ 
usable  components  could  then  be  selected  individually  without  retrieving 
the  entire  system  or  subsystem;  in  fact  the  capability  supports  a  multiple 
level  break-up  and  does  not  require  additional  component  part  storage  for 
the  levels.  The  user  can  then  individually  select  the  components  desired 
without  having  to  make  the  break-up  decisions  that  would  otherwise  be  made 
by  each  individual  user  thus  improving  overall  productivity. 

The  additional  advantage  of  the  component-of-components  strategy  is  that 
documentation,  test  drivers,  test  data,  and  testing  results  can  be  stored 
with  the  individual  components.  Likewise,  Problem  and  Change  Reports  can 
be  associated  with  the  individual  components  and  not  have  to  be  extracted 
from  a  collection  of  reports  related  to  the  system  or  subsystem  as  a 
whole.  The  prototype  repository  lists  any  lower  level  Component  as  a 
Component  Part  with  the  Component  Part  type  of  "COMPONENT".  The  user  can 
Copy  and/or  Subscribe  to  that  portion  of  the  reusable  system  or  subsystem 
that  is  of  interest  or  immediately  reusable. 

The  separation  of  components  from  within  other  components  does  require 
resources  in  the  component  supply  and  maintenance  process  but  these  com¬ 
ponents  can  be  more  reliable  and  traceable,  i.e.,  the  user  can  use  the 
STARS  Repository  search  capability  to  track  down  other  uses  of  the  com¬ 
ponent  to  higher  level  components  to  determine  just  how  the  lower  level 
component  is  used.  The  lower  level  component  can  be  used  in  one  or  more 
higher  level  components  in  the  repository,  e.g.,  the  STARS  Window  Manager. 
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4.2.5  COMPONENT  PART  STORAGE  AND  DISTRIBUTION 


Component  Parts  are  stored  in  files  external  to  the  relational  information 
required  to  manage  the  reusable  part.  In  order  to  retrieve  these  files 
for  distribution  to  repository  users,  there  needs  to  be  a  standard  naming 
convention  established.  The  ideal  convention  would  store  a  platform- 
independent  name  in  the  database  so  that  this  name  will  not  need  to  be 
changed  when  moving  or  installing  the  repository  onto  another  platform. 

The  system  developed  for  the  prototyped  repository  stores  all  file  names 
as  integers  and  a  mapping  algorithm  converts  this  number  into  a  pathname 
and  filename.  It  is  recommended  that  this  approach  be  kept;  the  use  of 
a  different  algorithm  is  supported,  though,  by  the  separation  of  all 
mapping  functions  into  one  Ada  package.  This  package  may  be  changed  in 
any  way  (except  for  the  parameters)  without  affecting  the  program,  e.g., 
the  pathname  and  filename  algorithm  can  be  changed  to  be  compatible  with 
the  STARS  Virtual  Operating  System  Interface  (VOSI). 


4.3  USER  INTERFACE 


This  section  reviews  the  lessons  learned  pertaining  to  the  means  of  re¬ 
laying  information  to  the  user.  The  following  topics  will  be  discussed: 

•  Screen  Layout 

•  Action/Hot  Keys 

•  Search  Criteria 

•  Help  Screens 

•  Exiting 

The  prototype  repository  (CDRLs  0530  and  1600)  used  a  form  of  display 
screen  management  that  allowed  the  user  to  maintain  the  context  of  the 
search  and  access  process,  i.e.,  the  STARS  Window  Manager.  A  window 
placement  algorithm  positioned  the  next  window  as  close  as  practical  to 
the  current  position  of  the  cursor.  This  algorithm  also  sized  the  wTindow 
to  match  the  data  to  be  displayed  without  the  user  having  to  scroll  the 
display,  unless  sufficient  space  was  not  available  for  an  entire  list  to 
be  displayed.  This  proved  useful  for  complex  search  and  browse  sessions 
(as  possible  in  Figure  3  on  page  30)  but  was  confusing  to  new  or  casual 
users  of  the  repository. 


4.3.1  SCREEN  LAYOUT 


The  screen  layout  as  implemented  in  the  R-Increment  has  been  found  to  be 
easy  to  use  and  interpret.  This  window  layout  contains  a  list  of  avail¬ 
able  actions  on  the  top  line,  followed  by  the  title  of  the  window  on  the 
second  line,  an  optional  subtitle  or  column  heading  on  the  third  line, 
an  information  line  on  the  bottom  of  the  window,  and  all  data  on  the  re¬ 
maining  (scrollable)  lines.  The  user  may  choose  which  object  in  the 
window  to  perform  an  operation  on  by  moving  the  highlighted  selection  bar 


Information  Gained  from  the  Performance 


14 


to  that  object,  and  then  pressing  the  associated  action  key,  as  described 
in  "Search  and  Access  Processing"  on  page  31. 

This  window  approach  presents  a  straight-forward,  context  sensitive 
interface  and  is  similar  to  that  used  in  many  commercial  products  from  a 
wide  range  of  vendors.  It  should  thus  be  familiar  to  a  wide  range  of 
users,  decreasing  the  time  needed  by  the  user  to  learn  the  interface  to 
the  STARS  Repository  System. 

Specifications  in  the  appendices  do  not  require  specific  window  or  screen 
layouts,  i.e.,  L’ne  implementation  can  be  complete  overlays  of  the  previous 
screen,  windows  with  one  or  more  screen  layout  algorithms,  or  other  forms 
of  split-screen  display  that  contain  the  required  content  and  format 
(Figure  1  on  page  26).  Highlighting  has  been  included  in  the  prototyping 
efforts  with  color  emphasis  on  help  (Figure  4  on  page  32)  and  warning 
(Figure  5  on  page  32)  or  error  messages  as  well  as  instructional  messages 
from  the  search  and  access  process.  This  has  proven  useful,  particularly 
with  the  multiple  window  overlays  that  appear  to  clutter  the  display 
screen . 


4.3.2  ACTION/HOT  KEYS 


The  actions  and  operations  listed  in  the  action  bar  were  originally  pro¬ 
vided  by  assigning  a  particular  operation  to  a  specific  function  key. 
It  was  soon  realized,  however,  that  not  all  platforms  provide  these 
function  keys.  An  alternative  was  derived  that  maps  an  operation  to  a 
standard  character  on  the  keyboard.  For  example,  the  function  that 
processes  the  selection  criteria  and  returns  the  components  matching  that 
criteria  is  represented  in  the  action  bar  as  'Process'  and  is  performed 
by  pressing  the  ' P'  key  on  the  keyboard.  This  mapping  is  conveyed  to  the 
user  by  highlighting  the  character  in  the  action  bar,  e.g.,  ' P *  is  high¬ 
lighted  and  capitalized  in  'Process'. 

Action  (or  Hot)  Keys  were  added  and  proved  easy  to  use  since  the  alpha¬ 
numeric  keyboard  was  not  used  except  to  enter  numeric  or  alphanumeric 
search  parameters,  i.e.,  fields  in  the  standard  user  input  forms  ("At¬ 
tribute  Search  Selection  Screens"  on  page  33) .  Simple  switching  in  or 
out  of  "input"  mode  allowed  the  standard  keyboard  to  be  used  for  all 
Action  Keys.  If  PFKs  are  used  they  should  not  be  described  on  the  Command 
Bar  thus  allowing  the  keys  to  be  remapped  to  be  consistent  with  the  ap¬ 
plication  programs  or  tools  used  with  the  STARS  Repository  . 

The  use  of  these  Action  Keys  is  dependent  upon  each  function  being  mapped 
to  a  unique  key  for  each  window.  For  example,  it  occurs  that  some  windows 
provide  both  an  EXPLAIN  and  EXIT  function.  In  order  to  prevent  a  colli¬ 
sion  of  function-to-key  mapping,  both  of  these  functions  cannot  be  mapped 
to  the  ' E '  key.  A  reasonable  solution  is  to  assign  EXPLAIN  to  the  'E' 
key,  and  EXIT  to  the  'X'  key  so  that  the  action  bar  would  look  like 

Explain  .  .  .  eXit 
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4.3.3  SEARCH  CRITERIA 


The  search  criteria  as  implemented  in  the  R-Increment  is  displayed  in 
alphabetical  order  on  one  screen.  This  appears  somewhat  overwhelming  to 
the  novice  user.  An  alternative  approach  has  been  derived  that  first 
presents  only  the  types  of  components  available  on  the  screen,  and  then, 
once  this  value  has  .been  assigned,  the  other  attributes  may  be  manipulated 
by  selecting  the  attribute  type  from  the  action  bar.  A  window  is  also 
provided  that  lists  all  attributes  that  have  been  selected  as  search 
criteria  by  the  user  and  the  values  assigned  by  the  user  to  these  attri¬ 
butes.  See  Figure  15  on  page  39  for  a  more  detailed  explanation  of  the 
screen  layout. 

The  primary  advantage  to  this  approach  is  that  the  user  is  not  inundated 
with  information  the  first  time  they  access  the  Repository.  The  attri¬ 
butes  are  still  there  for  the  user,  but  they  are  arranged  in  an  ordered 
way  so  particular  users  can  apply  the  search  mechanism  that  is  best  for 
the  user  or  application.  Other  search  methods  can  then  be  ignored.  For 
example,  for  a  person  who  prefers  to  use  a  simple  keyword  search,  a 
keyword  mechanism  should  be  provided.  That  user  may  base  his  search 
purely  upon  this  means,  or  may  combine  it  with  any  other  search  means, 
such  as  the  hierarchical  taxonomy  or  faceted  taxonomy. 


4.3.4  HELP  SCREENS 


It  has  been  found  that  the  greatest  assistance  that  can  be  provided  to  a 
user  is  a  help  screen  for  each  window  that  describes  what  the  window  does, 
the  functions  allowed,  and  the  means  of  activating  those  functions.  This 
method  of  conveying  information  was  selected  rather  than  putting  the  in¬ 
formation  directly  on  the  screen  for  several  reasons.  First,  a  separate 
help  window  allows  more  information  to  be  displayed,  especially  if  the 
help  window  may  be  scrolled  and/or  paged.  Second,  this  information  will 
not  need  to  be  seen  by  users  as  they  become  more  familiar  with  the  system. 
Placing  this  information  in  a  separately  called  help  window  allows  it  to 
be  seen  by  the  user  who  needs  it,  but  does  not  force  itself  on  the  more 
experienced  user.  Third,  more  screen  space  is  available  for  data,  per¬ 
taining  to  the  process  selected,  instead  of  being  used  to  display  static 
help  information.  For  example,  the  functions  provided  can  be  shortened 
to  one  word,  or  abbreviation  of  the  word,  in  the  action  bar  and  a  more 
detailed  explanation  of  the  function  can  be  given  in  the  help  window. 

All  of  the  help  information  has  been  collected  into  a  single  Ada  package 
specification  so  that  this  information  may  be  customized  to  each  specific 
platform. 


4.3.5  EXITING 


The  original  Repository  only  allowed  the  user  to  exit  from  one  window  to 
the  previous  window.  It  became  evident,  however,  that  a  fast  exit  was 
also  required  to  allow  the  user  to  exit  the  system  completely,  regardless 
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of  where  they  were.  This  was  especially  true  when  the  user  was  several 
screens  or  window-overlays  into  the  search  and  browse  process.  Instead 
of  requiring  the  user  to  repeatedly  press  the  exit  key  many  times,  a  Quit 
key  was  provided,  which,  after  verifying  that  the  key  was  not  accidentally 
pushed,  would  return  the  user  to  the  screen  immediately  preceding  the 
opening  screen  of  the  Repository  search  process,  i.e.,  to  the  STARS  Re¬ 
pository  System  Main  Menu. 


4.4  DATABASE 


This  section  describes  the  lessons  learned  pertaining  to  the  database. 
The  tables  are  discussed  in  more  detail  in  "Appendix  C.  Repository  Detail 
Design  Document"  on  page  62.  The  following  topics  will  be  discussed: 

•  Commercial  Database  Tools 

•  Table  keys 

•  Component  Specific  Attributes 

•  Facet  Flexibility 

•  Personnel/Organization  Representation 


4.4.1  COMMERCIAL  DATABASE  TOOLS 


A  commercial  Relational  Database  System  was  used  to  support  rapid  proto¬ 
typing  in  Task  IR40  (CDRL  1600).  In  some  cases  the  prototyped  capability 
was  generated  by  the  report  generation  capability  of  the  commercial  RDBMS, 
i,e.,  for  Change  and  Problem/Response  Reports  and  for  User  and  Organiza¬ 
tion  Registration  Forms.  This  was  productive  but  limits  the  portability 
of  the  prototype  to  other  commercial  RDBMS. 

Search  and  Access  capabilities  are  implemented  with  the  Ada/SQL  binding 
supported  by  the  commercial  RDBMS  (CDRL  1600).  The  Ada/SQL  Bindings  being 
developed  for  the  STARS  Program  should  be  used  to  replace  the  commercial 
bindings.  The  earlier  prototype  (CDRL  0530)  used  an  early  STARS  Program 
developed  Ada/SQL  Binding  but  the  implementation  proved  unsatisfactory 
(CDRL  0510).  Also,  the  forms  should  be  re-implemented  to  be  independent 
of  the  commercial  RDBMS.  In  a  few  cases  this  has  been  accomplished  (CDRL 
1600)  and  the  performance  improved  and  the  user  interface,  i.e.,  screen 
format  and  user  controls,  was  then  consistent  with  other  Search  and  Access 
screens . 


4.4.2  TABLE  KEYS 


The  components  and  parts  were  originally  identified  in  the  database  by 
the  unique  combination  of  name,  type,  and  version.  This  scheme  did  not 
allow  different  components  and  parts  of  the  same  type  to  have  the  same 
name,  which  does  occur  in  real  world  situations.  The  alternative  approach 
recommended  for  the  next  improvement  of  the  Repository  Prototype  assigns 
a  unique  random  number  to  each  component  and  part.  In  addition,  since 
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versions  of  components  and  parts  are  considered  separate  entities,  a 
unique  random  number  is  also  assigned  to  each  version  of  a  component  and 
part.  In  the  same  way,  a  unique  random  number  is  assigned  to  reports 
(both  change  and  problem  reports)  contracts,  organizations,  and  organ¬ 
izations  . 


4.4.3  COMPONENT  SPECIFIC  ATTRIBUTES 


As  more  than  one  type  of  component  was  supported,  it  became  apparent  that 
most  attributes  are  not  applicable  to  all  component  types.  In  fact,  a 
separate  classification  scheme  evolved  for  each  type  of  component  sup¬ 
ported.  In  order,  then,  to  keep  track  of  which  attributes  applied  to 
which  components,  the  attributes  which  were  common  to  all  components  were 
kept  in  the  COMPONENT  table  and  all  others  were  removed  to  separate  ta¬ 
bles,  one  table  for  each  type  supported.  Although  this  means  another 
table  join  is  needed  to  use  this  scheme,  it  saves  space  in  the  COMPONENT 
table  and  presents  a  better  abstraction  of  the  component  within  the  da¬ 
tabase.  Furthermore,  the  addition  and  removal  of  these  type-specific 
attributes  affects  only  those  components  of  the  one  type,  not  all  compo¬ 
nents  . 


4.4.4  FACET  FLEXIBILITY 


Analogous  to  the  problem  mentioned  in  the  above  section,  it  has  been  found 
that  no  one  facet  taxonomy  will  accurately  describe  the  domain  of  all 
component  types.  It  is  therefore  necessary  to  have  a  different  taxonomy 
for  each  component  type.  To  provide  multiple  taxonomies,  the  facets  and 
facet  terms  are  stored  in  a  separate  table  and  linked  to  the  COMPONENT 
table  by  the  unique  component  identification  number.  An  added  benefit 
of  this  arrangement  is  that  a  component  may  have  more  than  one  facet  term 
for  a  specific  facet.  This  benefit  can  best  be  seen  in  cases  where  a 
software  component  abstracts  a  data  object.  In  such  a  case,  many  facet 
terms  are  needed  for  the  FUNCTION  facet  to  describe  all  the  operations 
provided  by  the  component. 


4.4.5  PERSONNEL/ORGANIZATION  REPRESENTATION 


It  was  found  that  people,  more  often  than  not,  fill  multiple  roles  (Li¬ 
brarian,  Re-user,  Supplier,  Evaluator,  etc.)  in  the  operation  and  use  of 
the  STARS  Repository  System.  To  support  this  observation,  a  single  table 
was  designed  to  hold  the  vital  information,  such  as  name  and  username, 
for  all  users,  i.e.,  the  people  associated  with  an  organizations.  In¬ 
formation  describing  organization  and  contracts  related  to  the  repository 
contents  are  maintained  as  separate  tables.  This  eliminates  redundancy 
and  makes  it  simpler  to  maintain  accurate,  up-to-date  information  re¬ 
quired  to  manage  the  repository.  This  same  strategy  was  also  used  for 
other  common  information  that  was  to  be  used  for  multiple  Components  and 
Component  Parts,  e.g.,  Nation  table  that  contains  the  name  and  status  of 
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nations  other  than  the  United  States  with  respect  to  component  supply  and 
(  .stribution  (Figure  43  on  page  72). 

It  was  also  realized  that  mailing  addresses  of  people  are  not  necessarily 
static  objects,  so  the  mailing  address  is  only  kept  for  the  organization. 
This  scheme  makes  the  assumption,  which  is  considered  valid  for  all  cases, 
that  an  organization  will  know  how  to  reach  the  people  associated  with 
it.  The  information  was  also  used  in  the  prototype  repository  to  support 
particular  capabilities,  e.g.,  to  ensure  accurate  information  when  system 
or  component  error  report  are  generated  or  system  and  response  messages 
are  routed. 
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APPENDIX  A.  REPOSITORY  SYSTEM  REQUIREMENTS  SPECIFICATION 


The  STARS  Repository  System  shall  have  the  following  tools,  capabilities, 
and  characteristics.  The  list  is  included  to  define  the  minimum  set  of 
integrated  software  development  and  data  processing  facilities  required 
to  maintain  and  support  the  STARS  Repository  System  and  the  repository 
contents . 


A .  1  OPERATIONAL  REQUIREMENTS 


The  STARS  Repository  System  shall  support  the  following  capabilities  and 

performance  requirements: 

1.  A  system  with  dial-in  communications  for  remote  access  and  capable 
of  24-hour  operation  and  the  distribution  of  information  in  both 
hard-copy  and  electronic  form.  The  information  may  be  mail  or  user 
notes  and  reports  among  registered,  authorized  users.  This  informa¬ 
tion  shall  include  components  and  component  parts  selected  from  the 
STARS  Repository  by  a  registered,  authorized  user.  Authorized  users 
include  Suppliers,  Managers,  and  Subscribers  (i.e.,  re-users  of  the 
Work  Products  or  information). 

2.  System  and  database  performance  sufficient  to  ensure  two(2)  second 
response  for  trivial  transactions,  e.g.,  changing  the  selection  cri¬ 
teria  from  a  single  screen,  and  five(5)  seconds  on  a  trivial  search 
operation,  e.g.,  returning  a  single  screen  of  components  meeting  the 
pre-specif ied  selection  criteria.  These  times  are  to  be  met  at  least 
97%  of  the  time  for  TBD  simultaneous,  remote  users. 

3.  System  and  database  capacity  sufficient  to  retain  all  Operational 
Procedures,  Standards  and  Guidelines,  tools  for  component  collection, 
maintenance,  search,  access,  and  distribution  of  selected  components, 
and  storage  of  TBD  million  lines  of  Ada  code  and  associated  documents. 

4.  One  or  more  Ada  development  environments  for  individual  users  to  an¬ 
alyze,  compile,  build,  and  test  selected  components.  Each  supported 
environment  shall  include  at  least  one  validated  Ada  compiler,  text 
and  Ada  language-sensitive  editor,  an  Ada  run-time  environment,  and 
a  user-friendly  Ada  program  debug  capability. 

5.  One  or  more  Relational  Database  Management  Systems  (RDBMS)  to  store, 
control,  access,  and  manage  the  repository  contents.  This  includes 
report  generation  and  other  tools  to  monitor  content  usage  and  to 
control  the  set  of  authorized  users  and  organizations.  Generated 
reports  include  catalogue,  list  of  components  retrieved,  list  of 
parts  retrieved  by  component,  list  of  subscriptions  by  organization, 
list  of  users  by  organization,  and  list  of  components  by  contract  or 
supplier. 

6.  Tools  for  the  preparation,  formatting,  and  printing  of  documents  in 
the  Standardized  Generalized  Markup  Language  (SGML). 
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7.  A  configuration  management  system  to  control  information  added  to, 
maintained  in,  or  deleted  from  the  repository.  This  includes  repos¬ 
itory  content  and  quality  standards  as  well  as  reports  generated  with 
respect  to  the  repository  system  or  to  selectable  components  in  the 
repository. 

8.  An  access  security  system  that  provides  for  the  registration  of  users 

and  the  organizations  they  represent  or  support.  This  access  security 
includes  password  protection  mechanisms,  see  CSC-002-85  DoD  Password 
Management  Guideline,  April  12,  1985  (referenced  in 

F19628-88-R-0011) . 

9.  Other  applicable  requirements  as  defined  in  F19628-88-R-001 1  under 
Software  Engineering  Environment  (Preliminary  System  Description), 
under  STARS  Repository  System  (Preliminary  System  Description),  and 
within  referenced  documents  (Applicable  Documents  List). 


A. 2  REPOSITORY  MANAGEMENT  REQUIREMENTS 


The  STARS  Repository  or  Repository  System  shall  support  the  following 

management  and  operational  requirements: 

1.  Management  of  individual  files  containing  reusable  information  or 
selectable  elements  of  that  information.  Information,  information 
files,  and  related  reports  shall  be  maintained  in  separate  Libraries 
or  other  form  of  partitioning  as  required  to  meet  access  security  or 
other  control  requirements  and  restrictions  with  respect  to  access, 
distribution,  and  repository  storage  hierarchies,  e.g.,  archives. 
These  managed,  selectable  elements  will  be  called  parts. 

2.  Capability  to  define  and  redefine  Repository  Libraries,  to  limit  ac¬ 
cess  to  specific  libraries  by  user  and  by  organization,  to  support 
library  selection  by  authorized  users  for  a  single  search  operation, 
and  to  send/receive  an  entire  library  to/from  a  remote,  compatible 
repos itory . 

3.  Classification  of  parts  according  to  general  content.  General  con¬ 
tent  will  be  conveyed  by  the  part  type. 

4.  Capability  to  define  or  redefine  the  set  of  part  types. 

5.  Management  of  multiple  versions  of  a  part. 

6.  Designation  of  a  single  "default"  version  of  a  part  which  is  defined 
to  be  the  best  part  version  to  use.  The  determination  of  what  part 
is  "best"  is  left  to  the  part  supplier  or  a  part  (quality)  promotion 
process . 

7.  Capability  to  group  parts  of  differing  types  (of  information)  into  a 
cohesive  collection.  These  collections  will  be  called  components 
and  each  unique  mapping  of  part  types  to  components  will  be  called 

component  type. 

8.  Capability  to  define  or  redefine  the  set  of  component  types. 
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9.  Management  of  multiple  versions  of  a  component 


10.  Designation  of  a  single  "default"  version  of  a  component  which  is 
defined  to  be  the  best  component  version  to  use.  The  determination 
of  what  component  version  is  "best"  is  left  to  the  component  supplier 
or  a  component  (quality)  promotion  process. 

11.  Parts  must  be  shareable  among  components  and  the  users  provided  a 
method  to  determine  which  component  version  is  using  a  particular  part 
version. 

12.  Components  must  be  definable  as  a  set  of  parts  where  one  or  more  of 
the  parts  may  be  an  independent,  selectable  component,  i.e.,  compo¬ 
nents  may  have  unique  parts  but  contain  a  multi-level  set  of  compo¬ 
nents.  Each  level  of  components  is  indicated  by  a  part  type  of 
component.  The  fact  that  a  component  may  be  logically  in  one  or  more 
components  shall  have  no  impact  on  individual  subscriptions  or  copy 
operations . 

13.  Report  writing,  storage  and  retrieval  mechanism  shall  be  available 
for  access  by  users.  The  reports  shall  support  problem  and  problem 
resolution  documentation  with  respect  to  the  Repository  System  or 
specific  versions  of  a  component.  This  shall  include  the  documenta¬ 
tion  of  specific  changes  that  have  been  made  in  the  creation  of  new 
component  or  component  part  versions.  Problem  reports  shall  have  a 
display  and  control  status  of  at  least  "open",  "answered",  "approved" 
and  "closed"  where  the  answering,  approving,  or  closing  is  by  au¬ 
thorized  users  only. 

14.  Tools  shall  be  available  to  identify  and  maintain  a  list  of  valid 
users  of  the  system  as  well  as  other  ancillary  data  required  by  law 
or  the  contract  to  operate  the  STARS  Repository  System  (CDRL  1460) . 
The  user  information  includes  their  mailing  address,  the  organization 
they  represent  or  support,  and  an  optional  network  address.  The  or¬ 
ganization  information  can  provide  the  users  address,  the  organiza¬ 
tion's  address,  and  an  optional  network  address. 

15.  Tools  shall  also  be  available  to  manage  the  components  and  component 
parts  in  the  repository  as  well  as  associated  reports,  e.g.,  catalogs, 
problem  reports,  and  change  reports.  The  tools  should  also  provide 
for  automated  collecting,  maintaining,  distributing,  and  retiring 
components,  components  parts,  and  (repository  or  system)  reports.  The 
explicit  requirements  for  collecting,  filtering,  and  loading  infor¬ 
mation  into  the  repository  are  covered  under  Supply  Requirements  be¬ 
low  . 


A. 3  USER  INTERFACE  REQUIREMENTS 


The  STARS  Repository  and  Repository  System  shall  be  designed  and  imple¬ 
mented  to  meet  the  following  requirements: 

1.  The  user  shall  be  notified  at  sign-on,  i.e.,  when  the  Logon  Password 
has  been  validated,  how  to  start  the  STARS  Repository  System  proc¬ 
essing.  The  user  shall  also  be  notified  of  any  current  or  planned 
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conditions  that  could  affect  the  user  or  the  level  of  service  from 
the  repository. 

2.  The  Component  Search  and  Access  process  shall  be  implemented  to  be 
initiated  from  the  STARS  Repository  Main  Menu.  This  menu  shall  also 
contain  entries  to  initiate  or  review  Repository  System  Problem  Re¬ 
ports  as  well  as  to  access  general  information  describing  all  capa¬ 
bilities  that  are  available  to  the  user.  The  Main  Menu  or  lower  level 
menus  are  to  be  provided  for  authorized  users  to  initiate  all  proc¬ 
essing  related  to  repository  component  supply  (e.g.,  filtering), 
maintenance  (e.g.,  migration),  and  reuse  (e.g.,  search,  access,  and 
distribution) . 

3.  All  interactive  interfaces,  i.e.,  user  keyboard  inputs  and  display 
screen  outputs,  shall  have  a  standard  layout  or  format  and  terminology 
that  is  consistent  for  all  repository  commands,  process  responses, 
and  other  information  presented  by  the  Repository  System.  Included 
in  the  latter  are  information  presented  in  all  user  error  response, 
user  help,  or  other  forms  of  information  presented  to  the  user. 

4.  The  system  shall  provide  error  messages  for  all  invalid  user  requests 
or  commands  and  confirmation  messages  for  all  commands  that  result 
in  database  changes,  extended  processing  that  occur  before  responses, 
and  on  any  command  that  may  result  in  loss  of  information  for  the 
system  or  user.  The  latter  shall  also  be  in  the  form  of  a  user  con¬ 
firmation  input  if  the  processing  involves  major  impact  to  the  data¬ 
base,  e.g.,  deletion  of  a  report,  or  may  lead  to  significant  loss  of 
time  or  information  to  the  user,  e.g.,  to  quit  the  search  process  at 
any  processing  point  other  than  the  first  screen  below  the  Main  Menu. 


A. 4  SUPPLY  REQUIREMENTS 


The  component  supply  process  shall  be  automated  to  the  greatest  degree 
practical  to  reduce  the  cost  of  the  repository  operation  and  to  increase 
the  quality  of  the  repository  content,  i.e..  Components,  Component  Parts, 
and  related  Reports.  The  STARS  Repository  shall  contain  the  following 
tools  and  capabilities  to  ensure  a  predefined  level  of  quality  is  met  by 
all  components  before  they  are  added  to  the  repository  (CDRL  1460). 

1.  Ada  code  compiler,  executable  module  generator,  and  an  execution  en¬ 
vironment  sufficient  to  test  components  that  meet  a  specific  set  of 
predefined  STARS  guidelines  and  standards  shall  be  available  in  the 
STARS  Repository  for  authorized  users. 

2.  A  capability  to  initiate  existing  and  future  Software  Engineering 
Environment  (SEE)  processing  including  STARS  Program  specific  auto¬ 
matic  component  part  analysis  tools  (e.g.,  spelling  checkers,  com¬ 
plexity  and  other  metric  summaries,  control  and  data  flow  analyzers, 
security  and  completeness  testing)  shall  be  provided. 

3.  A  capability  to  sequence  the  execution  of  a  set  of  processes  or 
analysis  tools  and  capture  the  tool  outputs,  e.g.,  analysis  results, 
for  storage  as  a  Component  Part  or  Report  shall  be  provided. 


Appendix  A.  Repository  System  Requirements  Specification 


23 


4.  Completeness  (e.g.,  statement  data  rights,  abstracts,  keywords,  and 
other  prologue  information)  and  correctness  checks  (e.g.,  spelling, 
syntax,  and  semantics)  shall  include  all  items  listed  in  the  STARS 
Repository  Guidebook. 

5.  The  above  capabilities  shall  designed  and  implemented  to  be  re-used 
or  ported  to  other  SEEs,  e.g.,  the  various  component  supplier  or  re¬ 
user  environments.  This  shall  not  preclude  the  use  of  commercial 
products  in  the  STARS  Repository  that  require  purchasing  of  license 
by  the  supplier  for  the  supplier's  development  environment.  The  ca¬ 
pability  shall  allow  a  supplier  to  substitute  comparable  tools  (e.g., 
spelling  checkers  and  compilers)  but  does  not  imply  that  such  a  ca¬ 
pability  is  imposed  on  the  suppliers. 


A. 5  SEARCH  AND  ACCESS  REQUIREMENTS 

The  STARS  Repository  shall  be  designed  and  implemented  to  meet  the  fol¬ 
lowing  requirements : 

1.  All  search  processing  shall  be  performed  at  the  component  level. 

2.  Support  a  component  attribute  storage  mechanism  as  well  as  alphanu¬ 
meric  and  numeric  search  attribute. 

3.  Support  a  hierarchical  classification  mechanism  to  catalog  compo¬ 
nents  . 

4.  Support  a  faceted  classification  mechanism  to  catalog  components. 

5.  Support  a  keyword  storage  mechanism  as  well  as  a  user  selected  keyword 
searching  mechanism. 

6.  Support  the  above  searching  mechanisms  for  a  single  search. 

7.  Provide  a  catalog  generation  and  browsing  capability. 

8.  Provide  hard-copy  generation  and  distribution  of  all  repository  pro¬ 
cedures,  required  forms,  and  catalog  to  potential  users  of  the  re¬ 
pository. 

9.  List  all  versions  of  a  specified  component. 

10.  List  all  versions  of  a  specified  part  version. 

11.  List  all  part  versions  of  a  specified  component  version. 

12.  List  all  components  which  use  a  specified  part. 

13.  Browse  individual  part  versions. 

14.  Generate  or  answer  problem  reports  for  a  specified  component  version. 

15.  List  and  allow  browsing  of  problem  and  change  reports  for  a  specified 

component  version  or  change  reports  associated  with  a  specified  part. 
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16.  List  all  reports  by  the  date  created  with  the  latest  first. 

17.  Copy  to  the  default  directory  of  the  current  user. 

18.  Copy  all  required  parts  or  the  set  of  user  specified  parts  of  a  spe¬ 
cific  component  version  using  a  default  naming  convention. 

19.  Copy  individual  part  versions  to  the  file  name  and  directory  path 
provided  by  the  user,  i.e.,  within  the  default  directory  assigned  to 
the  user. 
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APPENDIX  B.  REPOSITORY  TOP-LEVEL  DESIGN 


The  following  paragraphs  describe  th  3  top-level  design  from  a  user 
standpoint,  i.e.,  user  commands  and  examples  of  screen  contents  are  in¬ 
cluded.  An  overview  of  component  search  and  access  is  presented,  followed 
by  additional  detail  on  the  search  process  and  processing  of  both  compo¬ 
nents  and  component  parts.  The  last  paragraphs  provide  an  brief  de¬ 
scription  of  the  STARS  Repository  support  capabilities,  i.e.,  "Component 
Supply  and  Filtering"  and  "Registration  Forms". 


B.l  SEARCH  AND  ACCESS  OVERVIEW 


The  design  approach  for  the  component  search  facility  of  the  STARS  Re¬ 
pository  System  provides  the  user  with  several  methods  of  searching  the 
repository  for  components  and  a  set  of  user  interface  displays  (i.e., 
screens,  panels,  windows,  etc.)  that  facilitate  that  process.  These 
screens  or  windows  within  screens  shall  be  designed  to  make  the  component 
search  efficient  and  easy  to  use. 


B.1.1  SCREEN  FORMAT 


The  general  format  for  all  of  the  component  search  screens  is  illustrated 
in  Figure  1.  Example  screens  in  the  following  subsections  do  not  contain 
the  Title  Line  but  the  optional  lines  are  included  and  the  screens  closely 
relate  to  the  Repository  Prototype  (CDRL  1600).  The  prototype  attempted 
to  reduce  the  number  of  lines  for  better  performance  for  low  speed  dial-up 
terminals,  e.g.,  VT100  compatible  terminals  operating  at  2400  baud.  The 
Message  lines  and  the  Help  lines  in  the  prototype  are  also  very  abbrevi¬ 
ated  screen  formats. 

+ . . . . + 

i  Title  Line  I 


Command  Bar  Line 


Subtitle  Line  (optional) 

+ - + . - - - 

|  000  |  Column-title  Line  (optional) 

4 - +  - . . 

I  I  /-\ 

|  |  Vertical  | 


|  |  000  |<--  Line(s)  Selection  List  j 

i  I  I  (optional)  |  | 

II!  W  I 

I  __+ . + . . . . . . .  I 

|  Instructions/Message  Area  (optional)  | 

+ . - . - . . + 


Figure  1.  Standard  Search  and  Access  Screen  Layout 
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The  requirements  section  of  this  document  provides  additional  detail  and 
rationale  for  this  screen  layout. 


B.1.2  DEFINITION  OF  TERMS 


Attribute  specify  the  use  of  numeric  and  alphanumeric  attributes  in 

the  search  criteria 

Browse  displays  component,  part,  or  object  highlighted  by  the 

cursor  in  browse  mode 

Changes  displays  the  list  of  change  reports  associated  with  the 

selected  component  or  component  part  version 

Class  specify  the  use  of  a  hierarchical  classification  in  the 

search  criteria 

Command  Bar  the  top  bar  of  the  STARS  repository  search  screens  that 
displays  the  action  choices  available  to  the  user  with  the 
currently  active  screen.  The  actual  choices  will  vary 
from  screen  to  screen.  Each  of  the  actions  is  associated 
with  a  unique  'hot  key',  that  is  displayed  in  upper  case 
and  highlighted  (i.e.  ,  the  'X'  in  eXit,  the  'E'  in  Explain, 
the  'S'  in  Specify,  etc.).  Therefore,  the  action  can  be 
initiated  via  its  designated  'hot  key'. 

Copy  initiates  the  copy  process  for  the  user  selected  component 

ct  individual  component  part 

Drop  allows  the  user  to  drop  a  subscription  to  the  component 

highlighted  by  the  cursor 

Exit  returns  the  user  to  the  previous  screen 

Explain  displays  a  description  of  the  current,  highlighted  se¬ 

lection  choice  (the  action  verb  'Explain'  is  synonymous 
with  the  term  describe) 

Facet  specify  to  use  of  facets  in  the  search  criteria 

Help  a  screen  explaining  the  current  screen  being  displayed, 

available  user  actions,  and  program  function  key  mappings 

Info  provides  the  user  with  attribute  information  about  the 

object  highlighted  by  the  cursor 

Keyword  specify  the  use  of  keywords  in  the  search  criteria 

Next  advances  the  user  to  the  next  level  of  classification, 

when  applicable 

Parts  displays  the  list  of  parts  that  make  up  the  component 

highlighted  by  the  cursor.  Some  component  parts  are  op- 
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tional  and  others  are  required  for  the  component  to  be 
considered  'complete'.  As  asterisk  will  be  displayed  to 
the  left  of  the  required  parts. 

Process  executes  a  repository  query  based  on  the  search  criteria 

specified  by  the  user  (the  action  verb  'Process'  is  syn¬ 
onymous  with  the  term  search) 

Quit  returns  the  user  to  the  STARS  Repository  Main  Menu 

Reports  allows  the  user  to  access  the  change  and  problem  reports 

associated  with  the  object  highlighted  by  the  cursor 

Reset  resets  (clears)  all  search  parameter  selections  indicated 

on  the  current  screen 

Specify  allows  assignment  or  reassignment  of  values  to  attributes. 

Select  allows  the  user  to  select  the  object  highlighted  by  the 

cursor;  usually  the  enter  key  will  perform  this  action 

Subscribe  allows  the  user  to  subscribe  to  the  object  highlighted  by 

the  cursor 

Summary  displays  the  user's  current  search  criteria.  Criteria  on 

the  screen  highlighted  by  the  cursor  can  be  toggled  off 
and  on. 

Top  returns  the  user  to  the  search  filed  screen  after 

progressing  several  layers  into  the  component  search  hi¬ 
erarchy 

Versions  displays  on-line  component  version  data  for  the  object 

highlighted  by  the  cursor 


B.1.3  METHODS  OF  SEARCHING 


The  component  searching  methods  provided  in  the  STARS  Repository  shall 
be : 

•  faceted  classification  scheme 

•  hierarchical  classification  scheme 

•  specification  of  search  attributes 

•  specification  of  search  keywords 

The  faceted  classification  scheme  shall  allow  the  specification  of  a  name 
that  represents  a  perspective,  viewpoint,  or  dimension  of  a  particular 
domain.  Each  facet  shall  be  represented  as  defined  in  (CDRL  1590)  as 
having  one  or  more  facet  terms  and  an  alias  list  associated  with  it. 

The  hierarchical  classification  scheme  shall  allow  specification  of  a 
subtree  of  the  hierarchy  as  well  as  individual,  terminal,  or  leaf-node 
hierarchical  entries  as  search  criteria. 
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Attribute  search  criteria  shall  typically  be  defined  as  an  exact  value 
or  as  a  range  of  numeric  or  alphanumeric  values.  Alphanumeric  attributes 
can  also  be  specified  as  a  list  of  values  to  search  or  a  pattern  using 
wildcards . 

The  Keyword  search  shall  provide  the  user  with  the  ability  to  indicate 
keywords  as  their  search  criteria. 

If  the  user  elects  to  use  the  attribute  or  keyword  option  as  his  search 
criteria  he  may  expand  the  attribute  or  keyword  specified  through  the  use 
of  a  'wildcard'  parameter. 

The  characters  selected  for  the  'wildcard'  parameters  are  the  (percent 
symbol)  "%"  and  the  (underscore)  (0RACLE_SQLREF88 ,  page  1-31).  The 
percent  sign  is  used  to  indicate  that  one  or  more  characters  may  be  placed 
in  the  space,  whereas  the  underscore  indicates  that  only  a  single  char¬ 
acter  may  fill  the  space,  as  shown  in  Figure  2. 


Query 

Possible  Results 

J0?4 

JOHN,  JOHNSON,  JOB, 

J0%N 

JOHN,  JOHNSON,  JON 

J0_ 

JOB,  JON 

JON 

JOHN 

12-MAY-* 

12-MAY- 1988,  12-MAY 

-MAY- 1989  01-MAY-1989  ...  31-MAY-1989 


Figure  2.  Examples  of  Wildcards  in  Search  Fields 


B.1.4  USER  INTERFACE 

As  stated  in  "Appendix  B.  REPOSITORY  TOP-LEVEL  DESIGN"  on  page  26  the 
component  search  process  of  the  STARS  Repository  System  is  available  to 
the  user  through  a  set  of  search  support  screens.  Selecting  the  'Component 
Search'  option  on  the  STARS  Repository  System  Main  Menu  provides  the  user 
interface  to  the  Component  Type  Selection  Screen.  An  example  of  the 
component  type  selection  screen  is  shown  in  "Component  Type  Selection 
Screen"  on  page  32. 

Figure  3  on  page  30  provides  an  overview  of  the  screen  support  that  shall 
be  provided  for  the  component  search  process. 
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Search  Processing 


Component  Processing 


Part  Processing 


User 

Logon 


+-> | STARS  Repository! - >  Other  STARS  Repository  System  Processing. 

4 —  |  Main  Menu  j 

|  + - 1-  Note:  Arrows  always  show  user  selection 

|  possibilities.  "Exit"  is  always  to 

|  + - 1-  previous  screen  and  "Quit"  returns 

+-> | Search  Types  and)  to  the  Main  Menu  from  any  screen. 

+--[  Component  Types |  Processing  may  have  lower-level 

j  4. - +  screens  and  controls  not  depicted. 


|->|  Attribute  | — I- >  |  Search  Process 


|  | Search  Criteria! 

I  + - + 


| -> |  Facets  &  Terms |-- 
|  | Search  Criteria! 

j  + . + 

I 

|  + . + 

|->(  Classification | -- 
|  |  Search  Levels  | 

j  + . + 

I 

|  4- - - + 

|->|  Keyword  |-- 

|  |  Search  Method  | 

j  + . . + 


4 — [Component  List  | 

|  4- . 4- 

I 

|  + . +  4- . . . 4- 

| ->  |  Component  Parts) - l-->|  Component  Part  |<-+ 

!  i  List  j<-+  |  !  Browse  or  Edit  j  [ 

|  H - 4-  I  I  H - +  I 


+  -> | Search  Criteria! — v 
|  Summary  | 

+ . . + 


-> | Component  Change |<- 
| /Problem  Reports! 

+ . + 


■> | Component  Attrs.|<- 
! for  this  Version! 

+ - + 


-> !  Component  Copy  | <- 
|  or  Subscription | 

+ - + 


->|  Component  Part  |<- 
|  Change  Reports  | 

+ . + 

+ . + 

■>|  Part  Attributes | <- 
| for  this  Version! 

4- - 4. 


->|  Component  Part  |<- 
I  Copy  j 

4. - 4. 


4— > |  Component  List  | --+  +->|  Comp.  Part  List| — H 

|  of  all  Versions |< - |  of  all  Versions! 

4. - 4.  + . . + 


Figure  3.  Overview  of  the  Search  and  Access  Process  Flow 

The  following  is  a  list  of  tentative  titles  for  the  component  search 
screens . 


•  Classifications  for  the  selected  component  type 

•  Components  returned  from  search 

•  Attributes  of  selected  component 

•  Pattern  for  a  selected  search  field 

•  Terms  for  the  selected  Facet 

•  Parts  of  selected  component 
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•  Change  Report  Options 

•  Problem  Reports  for  Selected  Component 

•  Information  for  Part 

•  Versions  of  Selected  Component 

•  Versions  of  Selected  Component  Part 

•  Components  using  Selected  Component  Part 

•  Component  Changes  to  Selected  Component 

•  Changes  to  Selected  Component  Part  version 

•  User  Subscription  Options 

•  Subscribed  to  Items 


B .2  SEARCH  AND  ACCESS  PROCESSING 


A  set  of  descriptions  of  the  component  search  and  access  screens  that  were 

referenced  in  "User  Interface"  on  page  29  are  presented  in  the  following 

paragraphs.  These  descriptions  will: 

•  state  the  primary  purpose  of  the  screen 

•  provide  an  example  of  the  screen  layout 

•  indicate  the  valid  actions  available  on  each  screen. 

The  following  operations  shall  apply  to  all  of  the  component  search  and 

access  screens. 

1.  The  cursor  will  be  positioned  on  the  object  to  be  processed  (in  the 
selection  list  area  of  the  screen)  by  the  user. 

2.  Pressing  the  'hot  key1  associated  with  an  action  (displayed  in  the 
action  bar)  will  apply  the  action  to  the  highlighted  object.  The  'hot 
key'  is  the  letter  in  the  action  verb  that  is  highlighted  and  in  upper 
case . 

3.  Pressing  the  Help  action  key  wrill  present  a  window  to  the  user  con¬ 
taining  additional  information  about  the  purpose  of  the  screen,  the 
functions  available,  and  the  means  of  performing  those  functions. 
An  example  help  window  is  shown  in  Figure  4  on  page  32. 
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+ . — . - . . . . + 

|  This  window  presents  the  component  types  j 
|  in  a  selection  list  format.  Once  one  of  I 
|  the  types  is  selected,  the  attribute  types  | 

|  on  the  action  bar  may  be  chosen  for  fur-  j 
|  ther  specification.  The  following  keys  j 
I  are  available:  I 


|  A  -  Specify,  a  character  or  numeric  j 

|  attribute  | 

|  C  -  Specify  the  hierarchy  value  j 

|  E  -  Display  an  explanation  of  the  j 

|  highlighted  object  | 

|  F  -  Specify  a  facet  term  | 

|  H  -  This  window  | 

|  K  -  Specify  a  keyword  attribute  j 

|  Q  -  Return  to  the  STARS  Repository  j 

|  Main  Menu  j 

|  S  -  View  or  specify  all  the  attributes  | 

|  related  to  the  selected  type  i 

|  X  -  Return  to  the  previous  screen  ! 

|  Enter  -  Select  the  highlighted  object  | 

+ . - . - . . . - . + 

Figure  4.  Example  of  a  Help  Window 


4.  If  the  Quit  action  key  is  pressed,  a  screen  shown  in  Figure  5  will 
ask  the  user  to  enter  ' Y'  to  exit  to  the  STARS  Repository  Main  Menu. 
If  any  other  key  is  pressed,  the  user  will  be  returned  to  the  previous 
screen. 


+ . - . + 

|  Do  you  wish  to  exit  the  Component  Search  tool?  | 

|  Press  ' Y '  to  exit,  any  other  key  to  cancel.  | 

+ . - . - . - . - . -+ 

Figure  5.  Example  of  the  Quit  Window 


B.2.1  SEARCH  PROCESSING 


This  section  will  describe  the  windows  used  to  establish  the  search  cri¬ 
teria  needed  to  find  a  specific  set  of  components.  The  first  section, 
"Component  Type  Selection  Screen",  presents  the  first  screen.  From  this 
screen,  the  other  attribute  specification  screens  may  be  invoked. 


B.2.1.1  Component  Type  Selection  Screen 


The  purpose  of  this  screen  shall  be  to  accommodate: 

•  selection  of  a  component  type 

•  specification  of  a  search  method. 
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The  component  types  appear  in  the  selection  list  portion  of  the  screen 
(i.e.,  DOCUMENT,  SOFTWARE,  etc.)-  An  example  of  the  component  type  se¬ 
lection  screen  is  shown  in  Figure  6  on  page  33. 

-I - 1- 

|  Attribute  Class  Explain  Facet  Help  Keyword  Quit  Summary  eXit  | 


STARS  Component  Type  Selection 


DOCUMENT 

SOFTWARE 


|  Select  the  component  type  before  initiating  the  specific  search  type.  | 
4 - (- 

Figure  6.  Example  of  the  Component  Type  Selection  Screen 

Valid  actions  on  the  screen  are 

Attribute  specify  the  use  of  alphanumeric  or  numeric  attributes  in  the 
search  criteria 

Class  specify  the  use  of  a  hierarchical  classification  in  the  search 
criteria 

Exit  Returns  the  user  to  the  previous  screen.  In  this  case,  performs 

the  same  function  as  Quit 

Explain  displays  a  description  of  the  current,  highlighted  selection 
choice 

Facet  specify  the  use  of  selected  facets  in  the  search  criteria 

Help  a  screen  is  displayed  to  explain  the  purpose  of  the  current 

screen  and  information  about  what  actions  are  valid  and  how  they 
are  invoked 

Keyword  specify  the  use  of  selected  keywords  in  the  search  criteria 

Quit  returns  the  user  to  the  STARS  Repository  Main  Menu 

Summary  displays  the  user's  current  search  criteria.  Objects  high¬ 
lighted  by  the  cursor  can  be  toggled  off  and  on. 


B.2.1.2  Attribute  Search  Selection  Screens 


The  purpose  of  this  screen  shall  be  to  show  the  current  selection  criteria 
for  the  Attribute  selection  method.  An  example  of  the  Search  Criteria 
Summary  (Attribute  Selection  Method)  screen  is  shown  in  Figure  7  on  page 
34 . 
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Figure  7.  Example  of  the  Attribute  Selection  Criteria  Screen 

Valid  actions  on  the  screen  are 

Exit  returns  the  user  to  the  previous  screen 

Explain  displays  a  description  of  the  current,  highlighted  selection 

choice 

Help  a  screen  is  displayed  to  explain  the  purpose  of  the  current 

screen  and  information  about  what  actions  are  valid  and  how  they 
are  invoked 

Process  executes  a  repository  query  based  on  the  search  criteria  spec¬ 
ified  by  the  user 

Reset  resets  (clears)  all  search  parameter  selections  indicated  on 
the  current  screen 

Quit  returns  the  user  to  the  STARS  Repository  Main  Menu 

Specify  allows  assignment  or  reassignment  of  values  to  attributes 

Select  toggle  individual  object  assignments  by  highlighting  the  ob¬ 
ject,  which  is  accomplished  by  pressing  the  enter  key 

The  screen  shown  in  Figure  8  shall  allow  the  user  to  indicate  the  pattern 

to  be  used  when  searching  a  particular  alphanumeric  search  field. 

+ - - - + 

|  Help  Process  Quit  Specify  eXit  ! 


Pattern  for:  NAME 


Pattern : 


Press  [Enter]  with  no  value  to  abort  the  Attribute  specification. 


Figure  8.  Example  of  the  Alphanumeric  Search  Field  Screen 

The  screen  shown  in  Figure  9  on  page  35  shall  allow  the  user  to  indicate 
the  pattern  to  be  used  when  searching  a  particular  numeric  search  field. 
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+ - - - - + 

|  Help  Process  Quit  Specify  eXit  | 

I - - - - — . - . - . I 

|  Numeric  Range  for:  SIZE  | 

I . . - - - - -  ! 

|  Lower  bound:  _  (  minimum  value  -  100  )  j 

|  Upper  bound:  _  (  maximum  value  -  10000  )  | 

I . — - - - - . I 

|  Press  [Enter]  with  no  value  to  abort  the  Attribute  specification.  | 

+ . . - . . . - . - . + 


Figure  9.  Example  of  the  Numeric  Search  Field  Screen 
Valid  actions  on  the  screens  are 


Help 


Process 

Quit 

Specify 

Exit 


a  screen  is  displayed  to  explain  the  purpose  of  the  current 
screen  and  information  about  what  actions  are  valid  and  how  they 
are  invoked 

executes  a  repository  query  based  on  the  search  criteria  spec¬ 
ified  by  the  user 

returns  the  user  to  the  STARS  Repository  Main  Menu 
allows  assignment  or  reassignment  of  values  to  attributes 
returns  the  user  to  the  previous  screen 


B.2.1.3  Hierarchical  Classification  Selection  Screens 


The  purpose  of  this  screen  shall  be  to  assist  in  the  tailoring  of  the 
search  criteria  through  a  more  'complete'  component  classification.  An 
example  of  the  Classifications  for  the  selected  component  type  screen  is 
shown  in  Figure  10. 


+ . - . . . . . . . - . 

|  Help  Next  Process  Quit  Specify  Top 

_ 

eXit 

---+ 

1 

i 

|  STARS  Repository  Classification 

1 _ 

i 

1 

| CLASSIFICATION 

l _ 

1 

1 

|0  STARS  PRIMES  -  INTERCHANGE 

1 

jl  STARS  Repository  Taxonomy 

1 

j  2  BOEING  DELIVERABLES 

1 

| 3  IBM  DELIVERABLES 

1 

| 4  UNISYS  DELIVERABLES 

1 

1 

|  Select/deselect  the  level  before  processing. 

+ . . - . . . - . 

1 

- + 

Figure  10.  Example  of  the  Hierarchical  Classification  Screen 
Valid  actions  on  the  'classifications'  screen  are 

Help  a  screen  explaining  the  current  screen  being  displayed,  avail¬ 

able  user  actions,  and  program  function  key  mappings 
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Exit 

Next 

Process 


Quit 

Specify 

Top 


returns  the  user  to  the  previous  screen 

advances  the  user  to  the  next  level  of  classification,  when 
applicable. 

executes  a  repository  query  based  on  the  selected  search  cri¬ 
teria  specified  by  the  user  (see  "Components  returned  from 
search"  on  page  39) 

returns  the  user  to  the  STARS  Repository  Main  Menu 
selects  the  highlighted  object  as  the  search  field  and  returns 
to  the  previous  screen.  May  be  performed  by  pressing  enter, 
returns  the  user  to  the  search  filed  screen.  See  "Hierarchical 
Classification  Selection  Screens"  on  page  35 


The  following  is  an  example  of  how  the  'next  level'  classification  screen 
will  be  formatted  assuming  the  STARS  Repository  Taxonomy  was  selected. 


j  Help  Next  Process  Quit  Specify  Top 

1 _ 

eXit 

---+ 

1 

|  STARS  Repository  Classification 

1 _ 

1 

| CLASSIFICATION 

1 _ 

1 

1 

| 1 . 1  Software  Building  Blocks 

! 

| 1 . 2  Software  Development  Support 

1 

| 1 . 3  Application  Support 

1 

1 

1 

|  Select/deselect  the  level  before  processing. 

1 

---+ 

Figure  11.  Example  of  a  lower  level  Classification  Screen 


B.2.1.4  Facet  Search  Selection  Screens 


The  purpose  of  this  screen  shall  be  to  show  the  current  selection  criteria 
for  the  Facet  selection  method.  An  example  of  the  Search  Criteria  Summary 
(Facet  Selection  Method)  screen  is  shown  in  Figure  12  on  page  37 
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Explain 

Help  Process 

Quit 

Reset  Specify 

eXit 

STARS  Repository 

Facets 

for  SOFTWARE 

Sel|  FACET 

(Current  Facet  Term) 

FUNCTION  (Eq  ANALYZE) 

LANGUAGE 

MEDIUM 

OBJECT  (Eq  STATISTICS,  REPORTS) 


Select/deselect  one  or  more  facets  before  search  processing. 


-+ 


Figure  12.  Example  of  the  Facet  Selection  Criteria  Screen 


Valid  actions  on  the  screen  are 


Exit 

Explain 

Help 


Process 

Quit 

Reset 

Select 

Specify 


returns  the  user  to  the  previous  screen 

displays  a  description  of  the  current,  highlighted  facet 
a  screen  is  displayed  to  explain  the  purpose  of  the  current 
screen  and  information  about  what  actions  are  valid  and  how  they 
are  invoked 

executes  a  repository  query  based  on  the  search  criteria  spec¬ 
ified  by  the  user 

returns  the  user  to  the  STARS  Repository  Main  Menu 
Resets  (clears)  all  the  selected  facets  and  their  facet  terms 
toggle  selection  of  individual  object  assignments  by  pressing 
the  enter  key 

allows  assignment  or  reassignment  of  values  to  attributes. 


The  screen  shown  in  Figure  13  shows  the  facet  terms  associated  with  the 
facet  and  search  field. 


+ - - 

|  Explain 

Help 

Process  Quit  Reset 

eXit 

- + 

1 

1 

Terms  for 

FACET:  FUNCTION 

1 

j Sell  FACET  TERM 

|  ALIASES 

|  |  ADD 

|  *  (ANALYZE 
|  | COMPARE 

|  | CHECK 

l  l 

|  EVALUATE 
j  EVALUATE 

1 

|  VERIFY, VALIDATE 

i 

1 

1 

1 

1 

|  ...  |  ... 

1 

|  Select  one  or 
+ . - 

more  facet 

terms . 

1 

----+ 

Figure  13.  Example  of  Facet  Terms  for  Selected  Facet  Screen 
Valid  actions  on  the  screen  are 

Exit  returns  the  user  to  the  previous  screen 
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Explain 

Help 


Process 

Quit 

Reset 

Select 


displays  a  description  of  the  current,  highlighted  selection 
choice 

a  screen  is  displayed  to  explain  the  purpose  of  the  current 
screen  and  information  about  what  actions  are  valid  and  how  they 
are  invoked 

executes  a  repository  query  based  on  the  search  criteria  spec¬ 
ified  by  the  user 

returns  the  user  to  the  STARS  Repository  Main  Menu 
deselects  all  selected  facet  terms  on  the  current  screen 
toggle  selection  of  individual  object  assignments  by  pressing 
the  enter  key 


B.2.1.5  Keyword  Search  Selection  Screen 


The  purpose  of  this  screen  shall  be  to  show  the  current  selection  criteria 
for  the  Keyword  selection  method  and  allow  this  selection  to  be  changed. 
An  example  of  the  Search  Criteria  Summary  (Keyword  Selection  Method) 
screen  is  shown  in  Figure  14. 


- - 1- 

|  Help  Process  Quit  Specify  eXit  | 


STARS  Repository  Keyword  Specification 


Current  keyword  value  : 
New  value  for  keyword  : 


|  Press  [Enter]  with  no  value  to  abort  keyword  specification.  | 

-I - - 


Figure  14.  Example  of  the  Keyword  Selection  Criteria  Summary  Screen 
Valid  actions  on  the  screen  are 


Exit 

Help 


Process 

Quit 

Specify 


returns  the  user  to  the  previous  screen 

a  screen  is  displayed  to  explain  the  purpose  of  the  current 
screen  and  information  about  what  actions  are  valid  and  how  they 
are  invoked 

executes  a  repository  query  based  on  the  search  criteria  spec¬ 
ified  by  the  user 

returns  the  user  to  the  STARS  Repository  Main  Menu 
allows  assignment  or  reassignment  of  values  to  attributes 


B.2.1.6  STARS  Repository  Search  Criteria  Summary 


The  purpose  of  this  screen  shall  be  to  list  the  search  fields  associated 
with  the  component  type  selected.  An  example  of  the  STARS  Repository 
Search  Field  Summary  screen  is  shown  in  Figure  15  on  page  39. 
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Explain  Help  Process 


Quit 


Reset  Specify  eXit 


STARS  Repository  Search  Field  Summary 


Sel|  SEARCH  FIELDS  (Current  Search  Value) 


AUTHOR  (Like  GRADY%) 

CLASS  (1.1  Software  Building  Blocks) 
DATE_ENTERED  (Like  _-DEC-1989) 
LANGUAGE 
KEYWORD 


Select/deselect  one  or  more  search  criteria  before  search  processing. 


Figure  15.  Example  of  the  Summary  Screen  Layout 
Valid  actions  on  the  screen  are 


Exit 

Explain 

Help 


Process 

Quit 

Reset 

Select 

Specify 


returns  the  user  to  the  previous  screen 

displays  a  description  of  the  current,  highlighted  selection 
choice 

a  screen  is  displayed  to  explain  the  purpose  of  the  current 
screen  and  information  about  what  actions  are  valid  and  how  they 
are  invoked 

executes  a  repository  query  based  on  the  search  criteria  spec¬ 
ified  by  the  user 

returns  the  user  to  the  STARS  Repository  Main  Menu 
resets  (clears)  all  selected  objects  on  the  current  screen 
toggle  individual  object  assignments  by  highlighting  the  object 
and  then  pressing  the  enter  key. 

allows  assignment  or  reassignment  of  values  to  attributes 


B .2.2  COMPONENT  PROCESSING 


This  section  describes  the  windows  that  display  information  and  relations 
about  components . 


B.2.2.1  Components  returned  from  search 


The  purpose  of  this  screen  shall  be  to  list  the  components  that  matched 
the  selection  criteria.  An  example  of  the  Components  Returned  from  Search 
screen  is  shown  in  Figure  16  on  page  40. 
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Help  Info 

Parts  Quit  Reports 

Subscribe 

Versions  eXit 

Components  returned  from 

search 

NAME 

|  TYPE 

CHARACTER -SET_ 

PACKAGE 

|  SOFTWARE 

DATE_PACKAGE 
FILE  OPERATIONS 


SOFTWARE 

SOFTWARE 


Select  component  before  processing. 


I 

-+ 


Figure  16.  Example  of  the  Components  Returned  From  Search  Screen 
Valid  actions  on  the  screen  are 


Exit 

Help 


Info 

Parts 


Quit 

Reports 

Subscribe 

Versions 


returns  the  user  to  the  previous  screen 

a  screen  is  displayed  to  explain  the  purpose  of  the  current 
screen  and  information  about  what  actions  are  valid  and  how 
they  are  invoked 

provides  the  user  with  information  about  the  object  high¬ 
lighted  by  the  cursor 

displays  the  list  of  parts  that  make  up  the  component  high¬ 
lighted  by  the  cursor.  Some  component  parts  are  optional  and 
other  are  required  for  the  component  to  be  considered  'com¬ 
plete'.  As  asterisk  will  be  displayed  to  the  left  of  the 
required  parts. 

returns  the  user  to  the  STARS  Repository  Main  Menu 
allows  the  user  to  access  the  change  and  problem  reports  as¬ 
sociated  with  the  object  highlighted  by  the  cursor 
allows  the  user  to  subscribe  to  the  object  highlighted  by  the 
cursor 

displays  on  line  component  version  data  for  the  object  high¬ 
lighted  by  the  cursor 


B.2.2.2  Versions  of  a  Selected  Component 


The  purpose  of  this  screen  shall  be  to  provide  version  information  about 
the  selected  component.  An  example  of  the  Version  of  selected  component 
screen  is  shown  in  Figure  17  on  page  41. 
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i  Help  Info  Parts  Quit  Reports  Subscribe 

. . + 

eXit  | 

i 

| Vers  ions  of  SOFTWARE 

:  EXTENDED  CHARACTER  UTILITIES 

1 

| VERS ION  |  DATE  | 

REASON 

| 

j  01.00  |  28-N0V- 1988  | 

|  01.01  |  14-MAR- 1989  | 

1  1  1 

Original  version 

Respond  to  Discrepancy  #24 

! 

1 

i 

|  .  .  .  1  •  *  *  1 

1 

1 

|  '  T  -  - | 

|  Select  component  version  before  processing.  I 

Figure  17.  Example  of  Versions  of  Selected  Component  Screen 
Valid  actions  on  the  screen  are 


Exit 

Help 


Info 

Parts 


Quit 

Reports 

Subscribe 


returns  the  user  to  the  previous  screen 

a  screen  is  displayed  to  explain  the  purpose  of  the  current 
screen  and  information  about  what  actions  are  valid  and  how 
they  are  invoked 

provides  the  user  with  information  about  the  object  high¬ 
lighted  by  the  cursor 

displays  the  list  of  parts  that  make  up  the  component  high¬ 
lighted  by  the  cursor.  Some  component  parts  are  optional  and 
other  are  required  for  the  component  to  be  considered  'com¬ 
plete'  . 

returns  the  user  to  the  STARS  Repository  Main  Menu 
allows  the  user  to  access  the  change  and  problem  reports  as¬ 
sociated  with  the  object  highlighted  by  the  cursor 
allows  the  user  to  subscribe  to  the  object  highlighted  by  the 
cursor 


B.2.2.3  Attributes  of  a  Selected  Component 


The  purpose  of  this  screen  shall  be  to  show  the  attributes  associated  with 
the  selected  component.  An  example  of  the  Attributes  of  selected  compo¬ 
nent  screen  is  shown  in  Figure  18  on  page  42. 
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Help 

Quit 

eXit 

Attributes 

of  SOFTWARE 

:  LIST 

DOUBLE  BOUNDED  MANAGED 

ATTRIBUTE 

|  VALUE 

AUTHOR  |  GRADY  BOOCH 

BOUNDING_INFO  j  BOUNDED 

CLASS  j  Lists 


I . ■'•+ . . I 

|Press  exit  key  to  return  after  scrolling  through  information.  | 

+ . - . . . --+ 


Figure  18.  Example  of  the  Attributes  of  Selected  Component  Screen 
Valid  actions  on  the  screen  are 

Exit  returns  the  user  to  the  previous  screen 

Help  a  screen  is  displayed  to  explain  the  purpose  of  the  current 

screen  and  information  about  what  actions  are  valid  and  how  they 
are  invoked 

Quit  returns  the  user  to  the  STARS  Repository  Main  Menu 


B.2.2.4  Report  Operations  Selection  Screen 


The  purpose  of  this  screen  shall  be  to  provide  the  ability  to  work  with 
and  or  view  problem  or  change  reports  associated  with  the  selected  com¬ 
ponent.  An  example  of  the  Change  Report  Options  screen  is  shown  in 
Figure  19. 

+ . - . . . . . . + 

|  Help  Quit  eXit  | 


Change  Report  Options 


Work  with  Problem  Report/Change  Request 
View  Problem  Reports 
View  Change  Reports 


Select  one  of  the  options  and  press  [Enter] . 


+ . . . . . - . + 

Figure  19.  Example  of  Change  Report  Options  Screen 
Valid  actions  on  the  screen  are 

Exit  returns  the  user  to  the  previous  screen 

Help  a  screen  is  displayed  to  explain  the  purpose  of  the  current 

screen  and  information  about  what  actions  are  valid  and  how  they 
are  invoked 

Quit  returns  the  user  to  the  STARS  Repository  Main  Menu 
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Select  allows  the  user  to  select  the  object  highlighted  by  the  cursor. 

If  that  object  is  the  'View  Problem  Reports’  item,  a  screen 
similar  to  the  one  described  in  "Problem  Reports  for  Selected 
Component"  on  page  43  will  be  displayed.  If  that  object  is  the 
'View  Change  Reports'  item,  a  screen  similar  to  the  one  de¬ 
scribed  in  "Component  Changes  to  Selected  Component  Version" 
will  be  displayed. 


B.2.2.5  Problem  Reports  for  Selected  Component 


The  purpose  of  this  screen  shall  be  to  allow  the  user  to  review  problem 
reports  for  the  selected  component  type.  An  example  of  the  Problem  Re¬ 
ports  for  "selected  component  type"  screen  is  shown  in  Figure  20. 


Browse 


Help 


Info 


Quit 


eXit 


Problem  Reports  for  CALENDAR  UTILITY 


-+- 


Title 


Date 


Unable  to  convert  to  European  standard 
Calendar  utility  test  program  report 


|  06-DEC-88 
j  03-N0V-88 

I  ... 

-+- . . 


Select  one  of  the  reports  and  press  [Enter]  to  Browse. 


Figure  20.  Example  of  the  Selected  Component  Problem  Report  Screen 
Valid  actions  on  the  screen  are 


B  rowse 

Exit 

Help 


Info 

Quit 

Select 


displays  the  highlighted  problem  report  in  the  mode  selected 

from  the  previous  screen 

returns  the  user  to  the  previous  screen 

a  screen  is  displayed  to  explain  the  purpose  of  the  current 
screen  and  information  about  what  actions  are  valid  and  how  they 
are  invoked 

provides  the  user  with  information  about  the  object  highlighted 
by  the  cursor 

returns  the  user  to  the  STARS  Repository  Main  Menu 
selects  the  currently  highlighted  report  for  browsing 


B.2.2.6  Component  Changes  to  Selected  Component  Version 


The  purpose  of  this  screen  shall  be  to  provide  information  about  component 
changes.  An  example  of  the  Component  Changes  to  Selected  Component  Ver¬ 
sion  scree-,  is  shown  in  Figure  21  on  page  44. 
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+ - - — . - . . . + 

|  Browse  Help  Info  Quit  eXit  | 

! . . . I 

|  Component  Changes  to  CALENDAR  UTiLITY  | 

j . + - + . j 

|  Version  |  Change_date  |  Title  | 

j  - . . + - + . . - . - . j 

|  01.01  |  31-0CT-1989  |  Leap  Year  Upgrade  \ 

|  01.00  j  04-JUL-1989  |  Support  European  Format  | 

j . + . + . . . . . . | 

|  Select  one  of  the  reports  and  press  [Enter]  to  Browse.  | 

^ - - - - - - - - - - - - + 


Figure  21.  Example  of  Component  Changes  to  Selected  Component  Screen 
Valid  actions  on  the  screen  are 


b  rowse 

Exit 

Help 


Info 

Quit 

Select 


views  the  highlighted  change  report 
returns  the  user  to  the  previous  screen 

a  screen  is  displayed  to  explain  the  purpose  of  the  current 
screen  and  information  about  what  actions  are  valid  and  how  they 
are  invoked 

provides  the  user  with  information  about  the  object  highlighted 
by  the  cursor 

returns  the  user  to  the  STARS  Repository  Main  Menu 
selects  the  highlighted  change  report  for  browsing 


B.2.2.7  Problem  Report  Options 


The  purpose  of  this  screen  shall  be  to  allow  several  operations  upon  a 
problem  report.  Once  the  user  selects  an  option  by  moving  to  the  appro¬ 
priate  line  and  pressing  Enter,  they  will  be  placed  in  the  corresponding 
window  as  shown  below. 

Submit  .  .  .  Figure  23  on  page  46 

Answer  ...  Figure  24  on  page  47 

View  ...  Figure  25  on  page  48 

An  example  of  the  Problem  Report  Options  screen  is  shown  in  Figure  22  on 
page  45 . 
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+ . - . . . - . + 

|  Help  Quit  eXit  | 


Problem  Report  Options 


Submit  a  problem  report 

Answer  a  problem  report 

View  a  problem  report 

Change  respondent  to  problem  report 


|  Select  one  of  the  options  and  press  [Enter] .  | 

+ - - - - - - - . . + 


Figure  22.  Example  of  Problem  Report  Options  Screen 
Valid  actions  on  the  screen  are 


Exit 

Help 


Quit 

Select 


returns  the  user  to  the  previous  screen 

a  screen  is  displayed  to  explain  the  purpose  of  the  current 
screen  and  information  about  what  actions  are  valid  and  how  they 
are  invoked 

returns  the  user  to  the  STARS  Repository  Main  Menu 
selects  the  highlighted  object  for  operation 


B.2.2.8  Component  Problem  Report  Submission 


The  purpose  of  this  screen  shall  be  to  allow  the  submission  of  a  problem 
report.  An  example  of  the  Component  Problem  Report  Submission  screen  is 
shown  in  Figure  23  on  page  46. 
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+ . . . . + 

|  Cancel  Help  Quit  eXit  | 


Component  Problem  Report  Submission 


Component  Name  :  _ 

Component  Type  :  _  Component  Version 


Component  ID  number  : 
Your  username  : 


Problem  Title: 


Problem  Description: 


|  Use  [Tab]  to  move  between  sections,  arrow  keys  to  scroll  text.  ] 

+ . . . - . + 


Figure  23.  Example  of  Problem  Report  Submission  Screen 
Valid  actions  on  the  screen  are 


Cancel 

Exit 

Help 


Quit 


returns  the  user  to  the  previous  screen  without  submitting  the 
problem  report 

returns  the  user  to  the  previous  screen 

a  screen  is  displayed  to  explain  the  purpose  of  the  current 
screen  and  information  about  what  actions  are  valid  and  how  they 
are  invoked 

returns  the  user  to  the  STARS  Repository  Main  Menu 


B.2.2.9  Component  Problem  Report  Submission 


The  purpose  of  this  screen  shall  be  to  allow  the  answering  of  a  problem 
report.  An  example  of  the  Component  Problem  Report  Answer  screen  is  shown 
in  Figure  23. 
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Cancel 


Help 


Quit 


eXit 


Component  Problem  Report  Answer 


Problem  Title:  _ 

Problem  report  number  : 
Your  username  :  _ 

Answer  Description: 


Use  [Tab]  to  move  between  sections,  arrow  keys  to  scroll  text. 


Figure  24.  Example  of  Problem  Report  Answer  Screen 

Valid  actions  on  the  screen  are 

Cancel  returns  the  user  to  the  previous  screen  without  submitting  the 
problem  report 

Exit  returns  the  user  to  the  previous  screen 

Help  a  screen  is  displayed  to  explain  the  purpose  of  the  current 

screen  and  information  about  what  actions  are  valid  and  how  they 
are  invoked 

Quit  returns  the  user  to  the  STARS  Repository  Main  Menu 


B.2.2.10  Component  Problem  Report  Viewing 


The  purpose  of  this  screen  shall  be  to  allow  the  viewing  of  a  problem 
report.  An  example  of  the  Component  Problem  Report  Viewing  screen  is 
shown  in  Figure  25  on  page  48. 
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+- - - - - 

|  Help  Quit  eXit 


Component  Problem  Report  Viewing 


Problem  report  number  : 
Problem  Title:  _ 

Problem  Description: 


Answer  Description: 


| Use  [Tab]  to  move  between  sections,  arrow  keys  to  scroll  text. 

4- . . . 

Figure  25.  Example  of  Problem  Report  Answer  Screen 

Valid  actions  on  the  screen  are 

Exit  returns  the  user  to  the  previous  screen 

Help  a  screen  is  displayed  to  explain  the  purpose  of  the  current 

screen  and  information  about  what  actions  are  valid  and  how  they 
are  invoked 

Quit  returns  the  user  to  the  STARS  Repository  Main  Menu 


B.2.2.11  User  Subscription  Options 

The  purpose  of  this  screen  shall  be  to  provide  the  user  with  a  facility 
for  subscribing  to  components.  An  example  of  the  User  Subscription 
Options  screen  is  shown  in  Figure  26  on  page  49. 


Reported  by  : 


Answered  by  : 
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Help  Quit  Select  eXit 
User  Subscriptions  Options 


Copy  a  Component 
Subscribe  to  a  Component 
Subscribe  to  and  Copy  Component 
Display  All  Subscriptions 


Select  from  the  options  and  press  [Enter] 


Figure  26.  Example  of  User  Subscriptions  Options  Screen 
Valid  actions  on  the  screen  are 


returns  the  user  to  the  previous  screen 

a  screen  is  displayed  to  explain  the  purpose  of  the  current 
screen  and  information  about  what  actions  are  valid  and  how  they 
are  invoked 

returns  the  user  to  the  STARS  Repository  Main  Menu 

allows  the  user  to  perform  the  object  highlighted  by  the  cursor. 


Quit 

Select 


If  the  object  is  'Copy  a  Component ' ,  a  screen  similar  to  Figure  27  is 
displayed.  If  the  object  is  'Display  All  ...',  a  screen  similar  to 
Figure  28  on  page  50  shall  be  provided. 


Browse  Copy 

Help  Info  Quit  Reset 

eXit 

Parts 

of  CALENDAR  UTILITY 

Sel|  Part  Type 

|  Part  Name 

|  Version 

*  |  BODY 

|  CALENDAR  UTILITY  BODY 

|  01.00 

DESCRIPTION 

HISTORY 

SPEC 


CALENDAR  UTILITY  DESCRIPTION 
CALENDAR  UTILITY  HISTORY 
CALENDAR  UTILITY  SPEC 


---+ . - . + - 

Select/deselect  Component  Parts  to  be  copied 


01.00 

01.00 

01.00 


Figure  27.  Example  of  Component  Parts  for  Component  Selected  for 
Copy 

Valid  actions  on  the  screen  are 

Browse  views  the  textual  information  associated  with  the  highlighted 
part 

Copy  copies  the  textual  information  associated  with  the  highlighted 

part  to  an  external  file 

Exit  returns  the  user  to  the  previous  screen 

Help  a  screen  is  displayed  to  explain  the  purpose  of  the  current 

screen  and  information  about  what  actions  are  valid  and  how 
they  are  invoked 
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Info 

Quit 

Reset 

Select 


provides  the  user  with  information  about  the  object  high¬ 
lighted  by  the  cursor 

returns  the  user  to  the  STARS  Repository  Main  Menu 
resets  (deselects)  all  selected  parts 

toggles  selection  of  part  for  inclusion  in  copy  process 


B.2.2.12  Subscribed  to  Items 


The  purpose  of  this  screen  shall  be  to  provide  the  user  with  a  method  of 
tracking  component  subscriptions.  An  example  of  the  Subscribed  to  Items 
screen  is  shown  in  Figure  28. 


+ . 

1 

1  --  - 

Drop  Help 

Info  Quit 

Reset 

eXit 

- + 

t 

1 

1 

Subscribed  to  Items 

- 1 

1 

i 

1  Sel  | 

Component  Name 

(Type) 

- 1 

1 

*  1 

CALENDAR  UTILITY 

(SOFTWARE) 

- 1 

1 

* 

EXTENDED  CHARACTER 

UTILITIES  (SOFTWARE) 

t 

1  1 

IBM  CDRL  1590 

(DOCUMENT) 

1 

1  1 

STACK  PACKAGE 

(SOFTWARE) 

1 

|  *  | 

i _ j_. 

WINDOW  MANAGER 

(SOFTWARE) 

1 

I 

i 

|  Select/deselect  one  or 

more  subscriptions 

to  drop. 

- 1 

1 

+ - 

- + 

Figure  28.  Example  of  Subscribed  to  Items  Screen 
Valid  actions  on  the  screen  are 


Drop 

Exit 

Help 


Info 

Quit 

Reset 

Select 


allows  the  user  to  drop  their  subscription  to  the  selected 
components 

returns  the  user  to  the  previous  screen 

a  screen  is  displayed  to  explain  the  purpose  of  the  current 
screen  and  information  about  what  actions  are  valid  and  how  they 
are  invoked 

provides  the  user  with  information  about  the  object  highlighted 
by  the  cursor 

returns  the  user  to  the  STARS  Repository  Main  Menu 

resets  (clears)  all  selections  indicated  on  the  current  screen 

toggles  selection  of  subscription  for  drop  process 


B  .2.3  PART  PROCESSING 


This  section  describes  the  windows  that  display  information  about  compo¬ 
nent  parts  and  there  relations. 
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B.2.3.1  Parts  of  Selected  Component 


The  purpose  of  this  screen  shall  be  to  show  the  component  parts  associated 
with  the  selected  component.  An  example  of  the  Parts  of  Selected  Compo¬ 
nent  screen  is  shown  in  Figure  29  on  page  51. 


+--- . - . . . . . . . - . + 

|  Browse  Changes  cOpy  Help  Info  Quit  Versions  eXit  i 

I  - . . . . . . . - .  -I 

| Parts  of  SOFTWARE  :  ADA  PROGRAM  FLOW  ANALYSIS  TOOL  (V01 - 00) | 

| - - --+ - + - - | 

j  TYPE  |  PART  |  VERSION  | 

j . . . + - + - j 

|  BODY  |  APFAT  MAIN  DRIVER  |  01.00  | 

|  COMPONENT  I  USER  INTERFACE  PACKAGE  |  01.02  | 

j  DESIGN  j  APFAT  DESIGN  NOTES  j  01.00  | 

|  RIGHTS  |  STANDARD  GENERAL  PUBLIC  RELEASE  |  01.03  | 

j  SPEC  |  APFAT  MAIN  DRIVER  |  01.00  | 

j . . -+ - +- . j 

|  Select  a  Component  Part  before  processing.  i 

+ . . . . . . + 


Figure  29.  Example  of  Parts  of  a  Selected  Component  Screen 
Valid  actions  on  the  screen  are 


Browse 

Changes 

Copy 

Exit 

Help 


Info 

Quit 

Versions 


displays  the  part  highlighted  by  the  cursor  in  browse  mode 
displays  a  list  of  all  change  reports  associated  with  this  part 
initiates  the  copy  process  for  the  user  selected  component  part 
returns  the  user  to  the  previous  screen 

a  screen  is  displayed  to  explain  the  purpose  of  the  current 
screen  and  information  about  what  actions  are  valid  and  how  they 
are  invoked 

displays  attribute  information  associated  with  the  highlighted 
part 

returns  tb'  user  to  the  STARS  Repository  Main  Menu 
displays  c  line  component  version  data  for  the  object  high¬ 
lighted  by  the  cursor 


B.2.3.2  Version  of  selected  part 


The  purpose  of  this  screen  shall  be  to  provide  version  information  about 
the  selected  part.  An  example  of  the  Version  of  selected  part  screen  is 
shown  in  Figure  30  on  page  52. 
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Browse 

Changes 

cOpy  Help  Info  Quit 

Using  eXit 

Versions  of 

RIGHTS 

:  STANDARD  GENERAL  PUBLIC 

RELEASE 

VERSION  | 

DATE 

|  REASON 

--+ - - 

01.03  |  18-DEC.-1989  |  Update  to  meet  new  regulations 

01.02  j  04-AUG-1989  |  Response  to  problem  #42 
01.01  j  12-MAR-1989  j  Include  non-govermment  rights 
01.00  j  28-N0V-1988  j  Original  version 


| - + - + - - - . | 

|  Select  a  Component  Part  Version  before  processing.  | 

+ . - . - . - . + 


Figure  30.  Example  of  Versions  of  Selected  Component  Part  Screen 
Valid  actions  on  the  screen  are 


Browse 

Changes 

Copy 

Exit 

Help 


Info 

Quit 

Using 


view  the  selected  component  part  in  browse  mode 
list  all  change  reports  associated  with  the  selected  part  ver¬ 
sion 

copies  the  selected  component  part  into  a  file  specified  by  the 
user  via  the  screen  shown  in  Figure  33  on  page  54. 
returns  the  user  to  the  previous  screen 

a  screen  is  displayed  to  explain  the  purpose  of  the  current 
screen  and  information  about  what  actions  are  valid  and  how  they 
are  invoked 

provides  the  user  with  information  about  the  object  highlighted 
by  the  cursor 

returns  the  user  to  the  STARS  Repository  Main  Menu 
displays  the  components  and  their  versions  that  use  the  se¬ 
lected  part.  This  information  is  displayed  in  Figure  34  on  page 
55. 


B.2.3.3  Information  for  Selected  Part 


The  purpose  of  this  screen  shall  be  to  show  the  attributes  associated  with 
the  selected  part.  An  example  of  the  Attributes  of  Selected  Part  screen 
is  shown  in  Figure  31  on  page  53. 
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Help 


Quit 


eXit 


Information  for  Part 


|  Name  :  CALENDAR  UTILITY 
|  Type  :  BODY 
j  Default  Version  :  01.01 
j  Owner  :  DOE,  JOHN 
|  Date  Entered  :  12-NOV-1988 

|  Press  the  exit  key  to  return. 

+ . - . . . . . - . . . 

Figure  31.  Example  of  the  Attributes  of  Selected  Part  Screen 
Valid  actions  on  the  screen  are 

Exit  returns  the  user  to  the  previous  screen 

Help  a  screen  is  displayed  to  explain  the  purpose  of  the  current 

screen  and  information  about  what  actions  are  valid  and  how  they 
are  invoked 

Quit  returns  the  user  to  the  STARS  Repository  Main  Menu 


B.2.3.4  Changes  to  selected  Part  Version 

The  purpose  of  this  screen  shall  be  to  provide  information  about  part 
changes.  An  example  of  the  Changes  to  a  component  part  version  screen 
is  shown  in  Figure  32. 


Figure  32.  Example  of  Component  Changes  to  Selected  Part  Screen 

Valid  actions  on  the  screen  are 

Browse  views  the  highlighted  change  report 
Exit  returns  the  user  to  the  previous  screen 

Help  a  screen  is  displayed  to  explain  the  purpose  of  the  current 

screen  and  information  about  what  actions  are  valid  and  how  they 
are  invoked 
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Info  provides  the  user  with  information  about  the  object  highlighted 

by  the  cursor 

Quit  returns  the  user  to  the  STARS  Repository  Main  Menu 


B.2.3.5  Component  Part  Copy 

The  purpose  of  this  screen  shall  be  to  allow  the  user  to  specify  a  file 
to  copy  a  single  part  to.  An  example  of  the  Component  Part  Copy  screen 
is  shown  in  Figure  33. 

+ . - . . . - . . + 

|  Help  Quit  eXit  | 


Copy  Part  Version  to  External  File 


|  Part  Version  :  WINDOW_MANAGER  (BODY)  VO  1.00  | 

|  External  file  name:  | 

I _ i 

I  I 

+ . . . . . . . . . . j 

|Press  [Enter]  with  no  file  name  to  cancel  operation.  | 

+ . - . . . . + 

Figure  33.  Example  of  Component  Part  Copy  Screen 

Valid  actions  on  the  screen  are 

Exit  returns  the  user  to  the  previous  screen 

Help  a  screen  is  displayed  to  explain  the  purpose  of  the  current 

screen  and  information  about  what  actions  are  valid  and  how  they 
are  invoked 

Quit  returns  the  user  to  the  STARS  Repository  Main  Menu 


B.2.3.6  Components  using  selected  component  part 

The  purpose  of  this  screen  shall  be  to  provide  information  about  which 
components  in  the  repository  are  using  the  selected  part.  An  example  of 
the  Components  Using  Selected  Component  Parts  screen  is  shown  in 
Figure  34  on  page  55. 
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Help  Info  Parts  Quit  Reports  Subscribe  Versions  eXit 


Comps  using  RIGHTS  :  TREE  ARBITRARY  DOUBLE  BOUNDED  MANAGED  (V01.00) 


NAME 

--+- 

1 

TYPE 

- +. 

1 

VERSION 

LIST 

DOUBLE 

BOUNDED 

MANAGED 

1 

SOFTWARE 

1 

01.00 

LIST 

DOUBLE 

BOUNDED 

CONTROLLED 

1 

SOFTWARE 

1 

01.00 

LIST 

DOUBLE 

BOUNDED 

CONTROLLED 

1 

SOFTWARE 

1 

01.01 

LIST 

DOUBLE 

BOUNDED 

UNMANAGED 

1 

SOFTWARE 

1 

01.00 

LIST 

DOUBLE 

BOUNDED 

UNMANAGED 

1 

SOFTWARE 

1 

01.01 

LIST 

DOUBLE 

BOUNDED 

UNCONTROLLED 

1 

1 

SOFTWARE 

1 

1 

01.00 

Select  a  component  before  processing. 

Figure  34.  Example  of  Components  Using  a  Part  Version  Screen 
Valid  actions  on  the  screen  are 


Exit 

Help 


Info 

Parts 

Quit 

Reports 

Subscribe 

Versions 


returns  the  user  to  the  previous  screen 

a  screen  is  displayed  to  explain  the  purpose  of  the  current 
screen  and  information  about  what  actions  are  valid  and  how 
they  are  invoked 

provides  the  user  with  information  about  the  object  high¬ 
lighted  by  the  cursor 

displays  the  component  parts  composing  the  selected  component 
returns  the  user  to  the  STARS  Repository  Main  Menu 
Displays  the  problem  and  change  report  options  for  the  se¬ 
lected  component 

displays  the  subscription/copy  options 

displays  on  line  component  version  data  for  the  object  high¬ 
lighted  by  the  cursor 


B .3  REPOSITORY  SUPPORT  OVERVIEW 


The  search  and  access  process  discussed  in  the  preceding  paragraphs  as¬ 
sumed  a  specific  set  of  processing  support  is  available,  i.e.,  to  ensure 
a  useful  set  of  components  is  available  in  the  Repository  and  that  accu¬ 
rate  information  is  available  that  describe  the  authorized  users.  This 
information  is  used  to  provide  default  values,  e.g.,  in  the  report  gen¬ 
eration  process. 


B.3.1  COMPONENT  SUPPLY  AND  FILTERING 


The  component  supply  process  will  evolve  as  the  repository  matures  and 
the  scope  of  the  contents  expands.  The  exact  processing  and  sequence  of 
processing  shall  be  as  defined  in  the  STARS  Repository  Operation  and 
Procedures  (e.g.,  CDRL  1470)  and  in  the  Repository  Guidebook  (e.g.,  CDRL 
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1550)  documents.  These  documents  define  the  processing  (either  manual 
or  automated)  that  are  required  to  add  a  component  to  the  repository  or 
to  remove  a  component  from  the  repository. 

The  processing  may  be  the  invocation  of  specific  tools  with  a  predefined 
input  script  or  on-line  input  from  the  user  invoking  the  tool.  In  the 
case  of  manual  processing,  the  tool  may  present  the  user  with  a  sequence 
of  manual  steps  required  to  complete  the  required  processing.  The  tool 
may  be  a  compiler  or  an  analysis  program  that  processes  the  source  data 
in  the  component  and  any  referenced  components,  e.g.,  any  referenced  code 
required  for  a  successful  compilation. 

Figure  35  includes  a  dispatcher  for  each  tool  which  may  be  required  if 
the  tool  is  not  compatible  with  the  Repository  System,  e.g.,  the  Virtual 
Operating  System  Interface  (VOSI)  environment  may  require  preprocessing 
or  post-processing  of  input  or  output  data.  The  control  process  is  re¬ 
ferred  to  as  the  Gatekeeper  and  the  unique  processing  required  to  inter¬ 
face  individual  tools  with  the  Repository  System  is  referred  to  as  the 
Dispatcher.  The  Gatekeeper  shall  interface  with  the  STARS  Repository  to 
assist  the  Repository  Manager  or  Librarian. 

The  tools  or  manual  process  will  provide  data,  e.g.,  files  or  reports, 
that  are  stored  with  the  component  when  the  component  is  accepted  into 
the  repository.  The  STARS  Repository  Manager  can  add  a  new  component  or 
a  new  version  of  a  component  to  the  repository  if  the  minimum  acceptance 
criteria,  as  defined  in  the  Operational  Procedures  and  User's  Guidebook 
(CDRL  1550),  are  satisfied  or  achieved.  An  automated  tool  dispatching 
process  has  been  prototyped  and  is  referred  to  as  the  Gatekeeper  (CDRL 
1570). 

+ -  STARS  Repository  Main  Menu  (Repository  Services) 

I 

|  + . . +  + - +  + . + 

II  II  II  I 

H — >|  Gatekeeper  | - >|  Tool_l  | - >|  Tooll  | 

I  |  I  Dispatcher  j  |  j 

I  II  I  I  I-+ 

+-- . . +  + - - +  |  + . +  | 

|  Tool_2  |-- . >|  Tool_2  | 

Note:  Arrows  always  show  |  Dispatcher  |  |  | 

authorized  user  (or  |  | — f-  |  j--+ 

a  predefined  script)  H - h  |  4- - h  | 

selection  sequence.  |  Tool_3  | - >|  Tool_3  | 

The  number  of  tools  |  Dispatcher  |  |  | 

and  execution  order  |  |  |  | 

shall  be  established  4 - 1-  4 - H 

by  modifiable  script.  ooo  ooo 


Figure  35.  Example  of  Dispatching  Repository  Tools 
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B.3.2  STARS  REPOSITORY  REGISTRATION  FORMS 


The  following  forms  are  for  information  that  will  usually  be  obtained  from 
a  prologue  section  of  a  component  submitted  to  the  repository.  It  may 
not  be  feasible,  however,  for  some  types  of  components  to  have  this  pro¬ 
logue.  It  is  also  likely  that  information  being  transferred  from  some 
other  repository  en  masse  will  not  have  this  prologue.  For  these  reasons 
the  forms  are  provided. 


B.3.2. 1  Component  Registration  Form 


The  first  form,  Figure  36  on  page  58,  contains  data  that  will  vary  de¬ 
pending  upon  the  type  of  component  being  submitted.  It  should  be  remem¬ 
bered  that  this  is  just  an  sample  form. 
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STARS  REPOSITORY  SYSTEM 
Component  Registration  Form 


Name: 


Version: 


Old  Component  ID: 


Access  Type: 


Contract  ID: 


Author  ID: 


Owner  ID: 


Attributes:  (Required  unless  supplied  in  the  Component  Prologue) 


Type: 


SOFTWARE 


Class : 


Media : 


Size : 


Structure : 


Format : 


Concurrency: 


Bounded : 


Media  Mgmt . : 


Iteration: 


Contact : 


User  Identification  Name: 


Organization  Identification  Number: 


Completed  by  Repository  System 


Repository  Entrance  Date:  _ 

New  Component  Identification  Number:  _ __ 

Notes:  Attach  Certificate  of  Origin  Forms  to  all  new  components 
and  revised/duplicate  forms  to  new  versions  of  components. 

Attach  Change  Reports  for  all  new  versions  of  registered 
components /component  parts  (by  Name  and  Version  Number). 


Figure  36.  Example  of  Component  Registration  Form 
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B.3.2.2  User  Registration  Form 


This  form  is  used  to  enter  in  data  for  any  person,  regardless  of  their 
role  in  the  Repository  (  Supplier,  Manager,  Re-user,  Owner,  etc.)-  This 
information  will  be  entered  only  once  for  each  person  and  will  be  modi¬ 
fiable  . 

STARS  REPOSITORY  SYSTEM 
User  Registration  Form 

Name:  _  _  _ 

(First)  (MI)  (Last) 

Title:  _  Position:  _ 

Nationality:  _  U.S. Status  _ 

Organization  Identification  Number:  _ 

Requested  User  Identification  Name:  _ 

Optional  Network  Address:  _ 

-  Completed  by  Repository  System  - 

Requested  User  Identification  Name:  _ 

Figure  37.  Example  of  User  Registration  Form 
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B.3.2.3  Organization  Registration  Form 


This  form  is  used  to  enter  in  data  for  any  organization  represented  in 
the  Repository.  This  information  will  be  entered  only  once  for  each 
person  and  will  be  modifiable. 


STARS  REPOSITORY  SYSTEM 
Organization  Registration  Form 


Organization : 


Address : 


(City)  (State)  (ZIP-Code) 

(Country)  (Phone  Number) 

-  Completed  by  Repository  System  - 

Organization  Identification  Number:  _ 

Qualified  Contractor  Access  Number:  _ 

Note:  The  above  registration  numbers  may  be  based  on  numbers  assigned 
to  the  attached  copy  of  DD  FORM  2245  approved  by: 

United  States/Canada  Joint  Certification  Office 
Defense  Logistics  Service  Center,  Federal  Center 
Battle  Creek,  MI  49017-3084 

Attach  one  or  more  completed  User  Registration  forms  and 
indicate  the  primary  (and  optional  alternates)  coordinators. 


Figure  38.  Example  of  Organization  Registration  Form 
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B.3.2.4  Contract  Registration  Form 


This  form  is  used  to  enter  in  data  eor  any  contract  represented  in  the 
Repository.  This  information  will  be  entered  only  once  for  each  person 
and  will  be  modifiable. 

STARS  REPOSITORY  SYSTEM 
Contract  Registration  Form 


Contract  Number: 
Contract  Name: 


Contracting  Agency: 


Contact  Name: 
Address : 


Optional  Network  Address:  _ 

-  Completed  by  Repository  System  - 

Organization  Identification  Number:  _ 

Contract  Contact  Identification  Name:  _ 

Figure  39.  Example  of  Contract  Registration  Form 
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APPENDIX  C.  REPOSITORY  DETAIL  DESIGN  DOCUMENT 

C.1  DATA  DICTIONARY 


1 

|  Data  Item 

!  Format 

| 

i 

Definition 

| 

1 

_l 

|  Component  id 

1 

| Integer 

i 

| 

1 

| Unique  number  identifying  a  partic¬ 
ular  component  of  a  particular  type. 

1 

i 

j 

|  Component  name 

1 

| Char  (40) 

i 

1 

|Name  of  a  reusable  object 

1 

_i 

|  Component  type 

|Char  (15) 

1 

| 

1 

|Type  of  the  reusable  object.  Examples 
| are  software,  documents,  plans. 

1 

i 

_i 

|  Component  ver¬ 
sion  id 

| Integer 

1 

1 

1 

1 

| Unique  number  identifying  a  partic¬ 
ular  version  of  a  particular  compo- 
|nent  of  a  particular  type. 

1 

n 

j 

| Part  id 

1 

Integer 

1 

i 

1 

| Unique  number  identifying  a  partic¬ 
ular  part  of  a  particular  type. 

1 

j 

|  Part  name 

I 

|Char  (40) 

1 

1 

. . . 

1 

|Name  of  a  text  file  which  contains 
| specific  information  about  a  compo- 
| nent . 

1 

j 

|  Part  type 

t 

|Char  (15) 

1 

1 

1 

|Type  of  the  information  to  be  used 
| f or  a  component.  Examples  are  ab¬ 
stract,  code,  test  driver,  license. 

i 

n 

j 

| Part  version 

1  id 

1 

| Integer 

1 

1 

1 

| Unique  number  identifying  a  partic¬ 
ular  version  of  a  particular  part  of 
|a  particular  type. 

1 

n 

i 

1 

| Person  id 

1 

1 

| Integer 

1 

1 

| 

1 

| Unique  number  identifying  a  specific 
| person  who  assumes  one  or  several 
| roles  within  the  repository. 

1 

n 

j 

| Owner 

1 

| Person  id 

1 

1 

1 

1 

1 

I 

|Name  of  the  individual  who  owns  and 
(is  responsible  for  a  component  or 
Ipart.  Note  that  the  same  owner  is 
| responsible  for  all  versions  of  the 

| component  part, 
i 

n 

j 

| Contributor 

| Person  id 

1 

1 

|The  individual  who  contributed  the 
| component  to  the  repository. 

1 

n 

j 

| Contact 

i 

1 

| Person  id 

1 

1 

1 

1 

_i _ 

1 

|The  individual  within  an  organization 
|who  is  the  representative  for  that 
| organization  in  regard  to  one  aspect 
|of  the  component,  such  as  the  con- 
j  tract . 

i 

n 

_i 
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Data  Item 


Format 


Definition 


|  Version 

H - 

|Char  (6) 

1 

1 

| 

— 1 - 

[Used  to  differentiate  objects  which 
[are  the  same  except  for  enhancements 
|and  corrections.  Also  appears  as: 

| component_version,  default  version, 

|and  part  version. 

1 

|  Vers  ion  reason 

I  Char  (80) 

1 

1 

1 

|Used  to  document  the  reason  that  a 
| new  version  of  a  component  or  part 
|has  been  entered  into  the  system. 

i 

|Date  entered 

t 

| DD-MMM-YYYY 

1 

1 

| Denotes  the  date  that  the  associated 

[object  was  entered  into  the  system. 

1 

| Part  required 

|Char  (1) 

1 

1 

1 

1 

1 

| Denotes  whether  a  specific  part  type 
[associated  with  a  specific  component 
| type  is  required  for  a  complete  com- 
Iponent  definition  or  operation. 

i 

|  Required  Indi- 
| cator 

1 

|Char  (3) 

1 

1 

I 

| 

1 

| Denotes  whether  the  object  is  Re- 
jquired  (REQ) ,  Optional  (OPT),  Multi¬ 
ple  values  allowed  (MUL) ,  or  Multiple 
| values/Optional  (MOP). 

1 

| Search  name 

1 

|Char  (20) 

1 

1 

I 

1 

1 

|The  name  of  a  search  field  which  can 
[be  used  to  locate  components.  Also 
| appears  as:  Facet_name  and 
[Attribute  name. 

i 

| Search  type 

1 

|Char  (13) 

1 

1 

| 

! 

[Indicates  the  type  of  search  field: 

| Facet,  Alphanumeric  attribute,  Nu- 
| meric  attribute,  or  Keyword. 

1 

Facet  term 

1 

iChar  (20) 

1 

| 

1 

|A  single  entry  in  the  enumerated  list 
|of  values  for  a  facet. 

1 

| Attribute 
| length 

t 

| Integer 

i 

i 

i 

1 

|The  maximum  length  allowed  for  the 
lvalues  of  a  particular  alphanumeric 
| attribute . 

1 

| Upper  bound 

1 

| Integer 

1 

l 

1 

|The  maximum  value  that  can  be  speci¬ 
fied  for  a  numeric  attribute. 

1 

] Lower  bound 

1 

| Integer 

i 

i 

1 

|The  minimum  value  that  can  be  speci¬ 
fied  for  a  numeric  attribute. 

1 

[ Descript  ion 

I 

iChar  (80) 

1 

! 

i 

1 

[Provides  some  additional  information 
| about  the  object  with  which  it  is  as- 
| sociated . 

1 

| Class  depth 

| Integer 

1 

1 

| Indicates  the  depth  in  the  hierarchy 
|of  the  associated  class. 
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Ill  I 


|  Data  Item 

|  Format 

| 

Definition  j 

|  Class  number 

1 

|Char  (40) 

1 

1 

1 

| 

Provides  a  numeric  designation  in 
character  form  for  the  associated  | 

class.  An  example  would  be  | 

"1. 1.3.2".  ! 

| Level  number 

| Integer 

1 

1 

1 

| 

Actually  is  8  fields:  Levi,  Lev2, 

. . . ,  Lev8 .  Indicates  the  number  of 
the  class  at  each  level  defined  for 
the  class.  | 

| Class  seq 

| Integer 

1 

1 

1 

| 

Random  number  (actually  assigned  as  | 
current  highest  +1)  that  is  used  to  | 
associate  class  entries  with  compo-  | 
nents .  j 

| Report 

t 

| Integer 

1 

1 

1 

_J _ 

Unique  number  identifying  an  external  | 
file  that  contains  textual  informa-  j 

tion  connected  with  a  problem, 
change,  component  part,  or  other  ob¬ 
ject.  | 

| Report  id 

1 

| Integer 

1 

Unique  number  identifying  a  partic-  j 

ular  report.  | 

| Organization 

j  id 

| Integer 

1 

1 

| 

Unique  number  identifying  a  partic-  | 
ular  organization  represented  in  the  | 
repository.  [ 

| Nation  id 

1 

|Char  (3) 

1 

i 

i 

Unique  character  string  identifying  a  | 
national  entity  represented  in  the 
repository.  | 

jus  Status 

r 

|Char  (1) 

1 

1 

1 

1 

1 

1 

Values:  Y  (the  object  is  considered  | 

to  be  an  entity  under  USA  laws  and  | 

regulations),  or  N  (the  object  is  not  | 
considered  as  such  and  may  be  under 
certain  regulations  as  to  shipping,  | 

passing  of  restricted  information, 
etc.) 

| Export  Control 
| Status 

i _ 

1 

|Char  (80) 

i 

i 

i 

String  containing  any  regulations  j 

pertaining  to  export  of  information 
in  the  repository.  | 

_ l 

Table  1.  Repository  Data  Dictionary:  This  table  contains  the  names, 
formats  and  definition  of  all  fields  used  in  the  Repository 
database . 
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C.2  DATA  NORMALIZATION 


The  abstracted  data  objects  for  the  STARS  Repository  will  be  developed  / 
presented  in  this  section.  The  objects  are  divided  into  the  following 
groups  for  purposes  of  discussion: 

1.  Component  Objects 

2.  Search  Objects 

3.  Component  Construction  Objects 

4.  Environment  Support  /  Information  Objects 

Each  of  these  groups  will  have  the  following  information  included: 
Definitions  Defines  the  objects 

Relationships  Gives  a  pictorial  representation  of  the  relationships 
among  the  objects  in  the  group 

Content  Lists  the  fields  which  make  up  the  object.  Also  identifies 

keys  . 


C.2.1  COMPONENT  OBJECTS 


Component  objects  define  the  component  units  and  the  relations  among  the 
text  units. 


C.2. 1.1  Definitions 

Component  A  component  is  the  collection  of  information  which  com¬ 

pletely  describes  a  reusable  object.  The  Repository 
will  support  multiple  versions  of  a  component. 

Part  A  part  is  a  single  instance  of  information  which  can  be 

used  to  describe  a  component.  The  Repository  will  sup¬ 
port  multiple  versions  of  a  part. 

Component  Parts 

Each  component  version  has  a  collection  of  parts  (with 
specific  versions)  specified.  Each  component  version 
has  at  most  one  part  of  a  particular  type,  unless  a  part 
is  another  component,  in  which  case  there  may  be  multi¬ 
ple  parts  of  this  type. 


C.2. 1.2  Relationships 
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+ - + 

|  Component  | 

+ . + . + 

I 

v 

+ - + 

|  Component  | 

|  Version  | 
+ . + . + 


+ . + 

|  Part  | 

+  --+ - + 

I 

v 

+- . + 

|  Part  | 

|  Version  | 

+ - + - + 

I 

+ - + 

v 


+ - + - +--+ 

|  Component  | 
j  Parts  ! 
+ - + 


Figure  40.  Component  Object  Relationships 


C.2.1.3  Object  Content 


Relation 


Key 


Component 


Component  Version 


Component  id 


Fields 


Component  name 
Component  type 
Default  version 
Owner 

Date  entered 


Used  to  record  the  existence  of  a  component. 
Search  fields  describe  objects  at  this  level. 


Component  version 
id 


Component  id  of 
parent  component 
Component  version 
Reason  for  ver¬ 
sion 

Date  entered 


|  Used  to  manage  multiple  component  versions. 
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Relat ion 


— 

1  Key 

i 

Fields 

1 

|  •  Part  id 

| 

j 

1 

! 

1 - 

•  Part  name 

•  Part  type 

•  Default  version 

•  Owner 

•  Date  entered 

Component  Part 


A  unit  of  text  to  be  managed  and  controlled 
by  the  STARS  repository.  This  element  may  be 
an  abstract,  license  agreement,  code,  test 
case,  etc.  and  may  be  referenced  by  more 
than  one  component . 

i - 

•  Part  version  id  |*  Part  id  for  par- 

|  ent  part 

| •  Reason  for  ver- 
!  sion 

|  •  Date  entered 

I 


Used  to  manage  multiple  part  versions. 


i 

•  Component  type  | •  Part  id 

•  Part  type  j 


|  Each  component  has  a  list  of  part  types  which 
|can  be  specified.  Only  one  part  can  be  de¬ 
fined  for  each  part  type. 


Table  2.  Component  Object  Content:  The  key  and  non-key  fields  are 
shown  for  each  component  object.  A  description  of  each  ob¬ 
ject  is  also  provided. 


C.2.2  SEARCH  OBJECTS 


Searci.  objects  describe  the  kinds  of  fields  which  can  be  used  to  classify 
and  s*  lect  components. 


C.2.2. 1  Definitions 


Search  Fields 
Hierarchy 


A  search  field  describes  some  property  of  a  component. 
A  tree  structured  classification  scheme. 


Hierarchy  Entries  The  individual  nodes  in  a  classification  tree.  Each 

node  can  have  child  nodes  or  matching  components. 
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Facets  A  search  field  which  has  a  predefined,  enumerated  list 

of  valid  character  values  and  describes  one  particular 
trait . 

Facet  Terms  The  enumerated  list  of  valid  character  values  for  a 

specific  Facet. 

Character  Attributes 

A  search  field  which  does  not  have  a  predefined  list 
of  valid  values  and  is  composed  of  character  values. 

Numeric  Attributes 

A  search  field  which  does  not  have  a  predefined  list 
of  valid  values  and  is  composed  of  numeric  values. 


C.2.2.2  Relationships 


+ - +  + - 

|  v  v 

| 

|  |  Hierarchy  | 

|  |  Entries  | 

|  + . + . + 

+ - + 

v 

+ - + . + 

|  Matching  | 

|  Component  | 
+ . . + 


+ 


+ 


|  Search  Fields  | 
+  . + - + 


+ - + - + 


v 

+---+ - + 

|  Facet  | 

|  Terms  | 

+ - + - + 

I 

v 

+ - + . + 

|  Matching  | 

|  Component  | 
+ - + 


v 

+ - +- . + 

|  Character  | 

|  Attributes  | 

+ - + - + 

I 

v 

+ - + . + 

|  Matching  | 

|  Component  | 

+ - + 


Figure  41.  Search  Object  Relationships 


- + 

v 

+ . + . + 

|  Numeric  | 

|  Attributes  | 

+ . + - + 


v 

+ - + - + 

|  Matching  | 

|  Component  | 
+ - + 


C.2.2.3  Object  Content 
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Relation 


Key 


Fields 


Search  fields 


Hierarchy  entries 


Facet  terms 


Numeric  Attribute 


Components  with  Nu¬ 
meric  Attributes 


Character  Attribute 


Search  name 


•  Search  type 

•  Description 


Components  with  Facet 
Terms 


|Defines  a  component  classification  view  (i.e. 

| Language,  Scope,  etc.)-  Search  type  is  hier¬ 
archy,  facet,  character  attribute,  numeric 
| attribute,  or  keyword. 


Class  name 
Class  depth 
Class  number 
Class  seq 
Class  description 


(Each  hierarchical  entry  contains  information 
|  tc  jllow  ordered  traversal  of  the  hierarchy 
|and  provides  the  capability  to  query  on  any 
I  class . 


Facet  value  key 
—  Facet  name 
Facet  term 


Description 

Aliases 


|  Each  facet  contains  an  enumerated  list  of 
|  facet  values  which  may  be  used  during  compo- 
|nent  supply  and  retrieval.  Nothing  is  im- 
|  plied  by  the  ordering  of  the  terms  within  a 
|  facet . 

I 


I  I 

|*  Facet  value  key 
|  (name+term)  I 

|  •  Component  id  ! 

| - i - 

| The  components  which  have  a  particular  char¬ 
acter  facet  value. 


Attribute  Name 


Upper  bound 
Lower  Bound 


[Numeric  attributes  require  the  definition  of 
valid  ranges. 


I 

•  Attribute  value  [ 

key  (name+value)  i 

•  Component  id 

- i - 

The  components  which  have  a  particular  nu¬ 
meric  attribute  value. 


Attribute  Name 


Attribute  length 


[Character  attributes  require  the  definition 
[of  valid  ranges. 
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Components  with  Char¬ 
acter  Attributes 


Key 


F ields 


Attribute  value 
key  (name+value) 
Component  id 


The  components  which  have  a  particular  nu¬ 
meric  character  value. 


Table  3.  Search  Object  Content:  The  key  and  non-key  fields  are  shown 
for  each  search  object.  A  description  of  each  object  is  also 
provided. 


C.2.3  COMPONENT  CONSTRUCTION  OBJECTS 


Component  construction  objects  dictate  what  kind  of  information  and 
search  mechanisms  are  available  for  different  types  of  components 


C.2.3. 1  Definitions 


Component  Type 

A  component  type  dictates  which  parts  and  search  criteria  are 
valid  or  required  for  a  component  of  the  type. 

Part  Type  Each  part  has  a  valid  type  which  determines  what  roles  that 
part  type  may  fill  for  a  component. 

Component  Part  Contents 

Each  component  type  defines  a  collection  of  part  types  that 
are  valid  or  required. 

Component  Search  Contents 

Each  component  type  defines  a  collection  of  search  fields 
that  are  valid  or  required. 


C.2.3. 2  Relationships 
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+ . . + 

|  Search  Fields  | 

+ . + . + 

I 

+ - + 


+ - + 

j  Component  Type  | 
+ - + - + 

I 

+ . + - + 


v  v 

+ — + - + . + 

|  Component  | 

|  Search  Contents | 
+ - - - + 


- +  +--- . --+ 

Type  |  |  Part  Type  | 

. +  + - + . + 

I 

- +  + - + 

v  v 

+ - + . + - + 

|  Component  j 
|  Part  Contents  | 

+ - + 


Figure  42.  Component  Content  Relationships 


C.2.3.3  Object  Content 


Relation 


Component  Content 
Parts 


Component  Content 
Search  Fields 


•  Component  type 

•  Part  type 


F ields 


Required  indica¬ 
tor 


|  A  "template"  which  dictates  which  parts  con¬ 
stitute  a  component. 


— 

|  •  Component  type 

•  Required  indica- 

|*  Search  field  name 

i _ 

tor 

_ 

i 

|A  "template"  which  dictates  which  search 

|  fields  are  required  for 

i 

a  component . 

Table  4.  Component  Content  Objects:  The  key  and  non-key  fields  are 
shown  for  each  component  content  object.  A  description  of 
each  object  is  also  provided. 


C .2.4  ENVIRONMENT  SUPPORT  /  INFORMATION  OBJECTS 


Environment  Support  /  Information  Objects  keep  track  of  information 
needed  to  support  the  development  system. 


C.2.4.1  Definitions 


Problem  report 

A  report  submitted  by  any  valid  user  stating  a  problem  found 
with  a  particular  version  of  a  component. 
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Change  report 

A  report  submitted  by  the  owner  of  an  object  stating  the 
changes  made  to  the  object  resulting  in  a  new  version  of  the 
object . 


C.2.4.2  Relationships 


+ - + 

+--|  Evaluation  | - f  -l - 1  Problem  | — f 

I  +- . . +  I  I  I  Report  j  | 

I  1  I  + - - +  I 

I  V  V  | 

|  H - h  -j - 1-  + - j-  | 

+--|  Verification  |-->|  Component  |<--|  Subscription  j--+ 
|  H - 1  j  Version  |  H - 1-  | 

I  + . +  I 

I  A  A  + . +  | 

I  + - - +  I  I  I  Change  |  | 

+  - -  |  Qualification  j - +  + - |  Report  j — 1 

I  + . +  + - - +  I 


|  |  Contract  |  |  Nation  |<--+  Person  |<- 

j  + - +  + . +  +-+ - + 

II  A  |  A  A 

IV  |  III 

+~+ - 1-  + - 1 - +  |  |  | 

|  Component  i - >|  Organization  |< - +  |  | 

+--- . +  + - - +  I  I 


-+  Change  | 

|  Report  j 
+ - + - + 


-+  +- 


+-+  Owned  H — >|  Part  | 

|  Item  |  |  Version  | 

+ - +  + - + 


Figure  43.  Environment  Support  /  Information  Object  Relationships 


C.2.4.3  Object  Content 
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Relation 


Fields 


Qualif icat ion 


Problem  Report 


Subscription 


Component  version 
id 

Evaluator 


Evaluation  date 

Rating 

Report 


An  evalutation  of  a  version  of  a  component 
and  the  determined  rating  based  on  the  ac¬ 
ceptance  criteria. 


Component  version 
id 

Verifier 


Verification  date 
Report 


A  verification  of  the  functionality  and  reus-  j 
able  quality  of  a  component.  j 


Component  version 
id 


Compiled 

Documented 

Tested 


_ 1 _ 

A  qualification  of  the  component  for  entry 
into  a  higher  level  repository  library. 


Component  version 
id 

Report  id 


Title 

Report  date 
Reporter 
Respondent 
Resolution  date 
Report 


A  report  submitted  by  any  user  noting  a  prob¬ 
lem  found  with  a  specific  component  version. 


Person  id 
Component  id 


Component  version 
id 

Subscription  date 


A  request  by  a  user  to  be  notified  of  all 
modifications/changes  affecting  a  particular 
component . 


Component  version 
id  OR 

Part  version  id 
Report  id 


Title 
Changer 
Change  date 
Report 


A  report  submitted  when  a  version  of  a  part 
or  component  has  been  changed,  explaining  the 
change(s)  made. 
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Relation 


T 


Key 


Fields 


Person 


Organization 


Nation 


Contract 


•  Person  id  | •  name 

| •  Network  address 
| •  Username 
|*  Nationality 

_ i _ 

A  record  established  of  every  user,  regard¬ 
less  of  position  (e.g.,  Qualifier,  Verifier, 
Evaluator,  Owner,  Contributor,  etc.) 


Organization  id 


Name 
Address 
Phone 
US  Status 


A  record  of  each  organization  represented  in 
the  repository  in  some  capacity. 


Nation  id 


Name 

Export  control 
status 


A  record  established  for  each  nation  repres¬ 
ented  in  the  repository. 


Contract  id 


Contract  number 
Contract  name 
Contracting 
agency 

Contacting  agen¬ 
cy's  contact 


|  The  contract  a  component  was  developed  under. 


Table  5.  Environment  Support  /  Information  Objects:  The  key  and 
non-key  fields  are  shown  for  each  component  content  object. 
A  description  of  each  object  is  also  provided. 


C .3  RELATIONAL  DESIGN 


This  section  will  present  processing  model  of  data.  This  will  be  the 
program  "view"  of  the  data  and  will  not  change  regardless  of  the  DBMS  used 
in  implementation. 


C.3.1  PROCESSING  REQUIREMENTS 

The  component  search  and  access  processing  requirements  will  be  investi¬ 
gated  . 
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In  each  of  the  processes  sections,  the  tables  will  contain  a  dashed  line 
(" - ").  Processes  above  this  line  are  table  lookups,  and  the  costs  in¬ 
volved  will  not  be  discussed  since  they  are  assumed  to  be  minimized. 

Processes  below  the  dashed  line  involve  table  joins  or  some  other  complex 
searching  and  will  be  discussed  individually. 


C.3.1.1  Search  processes 


1.  List  all  selectors. 

2.  List  hierarchy  entries. 

3.  List  all  terms  for  a  facet  selector. 

4.  List  valid  range  for  a  numeric  selector. 

5.  List  valid  range  for  a  character  selector. 


6.  Selection  of  components  by  search  values. 

7.  Display  all  search  field  values  for  a  selected  component. 

8.  Find  all  common  search  fields  for  the  set  of  selected  components. 

Selection  of  components  by  search  values:  Third  normal  form  (TNT)  dic¬ 
tates  that  the  components  which  match  search  values  be  stored  by  search 
value  r object  key  would  be  search  field  +  search  value  +  component  id) . 
Searching  on  n  fields  would  require  that  n  table  ic'..c  be  performed. 

Display  all  search  field  values:  With  the  search  field  tables  set  up  as 
previously  described,  an  "open  join"  would  have  to  be  pei formed  on  n 
tables  to  get  the  values.  Since  cue  open  oin  operation  is  not  a  standard 
SQL  capability,  the  processing  (and  coding)  for  this  query  are  even  r.e 
difficult . 

Find  all  common  search  fields:  For  the  set  of  component  selected,  find 
all  search  fields  which  are  common  to  all  the  components  in  the  set.  This 
capability  allows  the  user  to  select  additional  search  fields  to  specify 
in  the  search  query. 


C.3.1.2  Component  processes 


1.  List  all  versions  of  a  component. 

2.  List  the  parts  used  by  a  component  version. 

3.  List  all  versions  of  a  part. 


4.  List  all  components  (or  versions)  which  use  a  part  (or  versions). 

List  all  components  which  use  a  part:  In  the  case  where  all  component 
versions  are  to  be  listed  for  a  particular  part  version,  this  is  a  simple 
table  lookup  with  multiple  matches.  In  the  other  cases: 

•  All  components  for  a  particular  part  version 

•  All  components  for  a  particular  part 

•  All  component  versions  for  a  particular  part 
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the  table  must  be  GROUPED  BY  and  ORDERED  BY  the  appropriate  fields. 


C.3.1.3  Content  processes 


1.  List  required  parts  for  a  component  type. 

2.  List  required  selectors  for  a  component  type. 


C.3.1.4  Support  processes 


1. 

2. 

3. 

4. 


List  all  problem  reports  for  a  component  or  part 

List  all  critiques  (  evaluations,  verifications,  etc.)  for  a  partic¬ 
ular  component 

List  all  subscribers  to  a  component  (or  version) 

List  all  changes  to  a  part  version  or  component  version 


5.  List  all  changes  to  a  component  or  part 

List  all  changes  to  a  component  or  part:  In  the  case  where  all  change 
reports  are  to  be  listed  for  a  particular  part  or  component,  this  set  of 
changes  to  versions  of  the  component  must  be  retrieved,  indicating  a  join 
of  the  Component,  Component  Versions,  and  Changes  tables. 


C.3.2  TRANSFORMATION  RATIONAL 


Due  to  processing  needs,  it  may  be  necessary  to  violate  TNF  supplied  in 
the  section  above.  If  so,  rational  /  justification  will  be  presented. 

The  following  objects  will  be  folded  into  the  Component  object: 

•  Matching  Component  by  Hierarchical  Classification. 

•  Matching  Component  by  Facet  and  Facet  Term 

•  Matching  Component  by  Character  Attribute 

•  Matching  Component  by  Numeric  Attribute 

This  is  done  for  efficiency  of  the  search  operation.  To  allow  for  mul¬ 
tiple  types  of  components,  all  attributes  that  are  dependent  upon  the 
component  type  will  be  moved  to  a  separate  table  reserved  for  these  at¬ 
tributes.  Thus,  there  will  exist  a  table  for  each  type  of  component  de¬ 
fined  whose  columns  will  be  the  attributes  unique  to  the  particular 
component  type.  Another  table  will  map  the  type-specific  attributes  ta¬ 
bles  to  the  component  types.  The  alternative  of  this  method  would  be  to 
keep  ALL  attribute  values  in  the  COMPONENT  table,  and  only  have  values 
assigned  to  those  attributes  which  apply.  This,  however,  would  leave  a 
large  amount  of  database  space  unused  in  any  system  that  supports  more 
than  one  type  of  component.  The  facets  will  be  considered  a  unique  type 
of  attribute  and  as  such,  the  facet  terms  for  a  component  will  not  be 
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stored  in  the  above  mentioned  type-specific  tables,  but  will  be  kept  in 
a  separate  table. 

The  results  of  these  actions  will  be  that,  at  most,  eight  tables  need  to 
be  joined:  the  Component  table,  the  type-to-specif ic-f ields  table,  the 
specific-fields  table,  the  facet  table,  the  hierarchy  table,  the  person 
table,  the  organization  table,  and  the  contract  table.  This  case  occurs 
when  at  least  one  of  each  attribute  type  is  used  for  the  search.  If  one 
type  of  attribute  is  not  used,  however,  then  its  tables  will  not  need  to 
be  included  in  the  search,  so  that  the  best  case  scenario  would  be  a 
search  on  only  those  fields  in  the  Component  table.  It  may  prove  valuable 
to  duplicate  the  person's  name,  organization's  name,  and  contract  number 
as  character  fields  in  the  component  table  to  prevent  the  join  of  the  last 
three  tables  mentioned.  This  can  be  determined  after  some  real-world 
evaluation  which  would  determine  exactly  how  often  these  tables  are  ac¬ 
tually  involved  in  the  search  process. 

The  hierarchy  will  be  represented  as  a  flat  table  with  an  numerical  entry 
for  each  level  of  the  classification.  This  is  done  because  SQL  databases 
do  not  support  recursive  relations.  Since  ordering  must  be  maintained 
and  duplication  of  class  names  is  allowed,  the  primary  key  of  this  re¬ 
lation  will  be  the  level  numbers.  Joins  to  the  component  table  will  be 
performed  on  a  meaningless  number  present  in  both  tables.  For  example, 
if  the  user  requested  that  all  components  in  class  ”2.1.3  Data  Structures" 
should  be  found,  the  query  to  perform  this  would  be: 

select  COMPONENT 

from  HIERARCHY  H,  COMPONENT  C 

where  H.LEV1  =  2  and  H.LEV2  =  1  and  H.LEV3  =  3  and  H.SEQ  =  C.HIERSEQ 

This  would  retrieve  all  components  whose  first  three  levels  of  hierar¬ 
chical  classification  was  "2.1.3". 


C  .3.3  PROCESS  TABLE  CONTENT 


Following  is  a  listing  of  the  relational  tables  to  be  used  in  processing. 
Each  will  include  the  following  items: 


Object  keys  which  enforce  uniqueness 
Recommendations  for  data  fields 


The  prim'^'y  k»y  cf 
enforce  uniqueness . 
the  order  listed  ir. 


every  table  will  be  implemented  as  a  unique  index  to 
The  fields  which  make  up  the  unique  key  will  be  in 
the  table. 
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SQL  Table 

1 

| 

Object  Key 

Data  Fields 

_ 

1 

1  * 

Component  id 

•  Component  name 

1 

•  Component  type 

•  Default  version 

Component 

1 

•  Owner 

1 

•  Contributor 

i 

•  Date  entered 

1 

•  Hier  Seq 

i 

1 

•  (Search  field...) 

_ 

1 

j  • 

Component  version 

•  Component  id 

Component  version 

1 

id 

•  Component  version 

I 

1 

•  Version  reason 

1 

1 

•  Date  entered 

_ 

1 

]  • 

Part  id 

•  Part  name 

•  Part  type 

Part 

1 

•  Default  version 

1 

•  Owner 

1 

•  Date  entered 

1 

1 

|  • 

Part  version  id 

•  Part  id 

1 

•  Part  version 

Part  version 

1 

•  Version  reason 

1 

•  Date  entered 

1 

•  Report 

_ I _ 

_ 

Component  Part 

1 

1  • 

Component  id 

•  Part_type 

1 

1 

•  Part_version_id 

n 

Search  fields 

I 

1  • 

Search  name 

•  Search  type 

1 

_  i 

•  Description 

n 

Facet  terms 

I 

|  • 

Facet 

•  Aliases 

1  • 

.  -  | 

Facet  term 

•  Description 

n 

Num  attrs 

1 

1  • 

Attribute  name 

•  Upper  bound 

1 

1 

i 

•  Lower  Bound 

n 

i 

Alpha  attrs 

j 

j  • 

-  1 

Attr ibute^name 

•  Attribute  length 

n 

Comp  keywords 

1 

[  • 

1 

Keyword 

•  Component  id 

h 

Comp  cont_parts 

I 

[  • 

Component^  ype 

•  Part_required 

1  • 

1 

Part  type 

r 

Comp  cont  Search 

! 

1  • 

Component_type 

•  Search_required 

|  • 

I 

Search  name 

r 

1 

j  • 

Levi 

•  Class  name 

Hierarchy 

1  • 

Lev2 

•  Class  number 

1  • 

. 

•  Sequence 

L_ 

I  • 

_ 1 _ 

Lev8 

|#  Class  depth 

i 
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1  1 — 

|  SQL  Table  | 

1  i 

Object  Key 

l  1 

|  Data  Fields 

1  i 

r  1 

|  Type_Specif ic  Fields  |* 

Component  Type 

1  1 

|  •  Specific  Field  | 

i  i 

j  Table  Name  j 

_ l _ l 

Table  6.  Process  SQL  table  content:  This  table  provides  the  object 
key  and  data  fields  for  each  SQL  table  in  the  Repository 
design.  Eacn  object  key  is  to  be  defined  as  a  unique  key 
to  enforce  uniqueness.  Additional  indexing  recommendations 
are  given  in  "Additional  Indexes"  on  page  81. 

In  addition  to  these  tables,  another  table  is  needed  to  support  use  the 
facets  to  describe  a  component.  The  following  table  will  allow  a  compo¬ 
nent  to  have  multiple  facet  terms  for  a  particular  facet. 


i  r 

|  SQL  Table  | 

1  t 

Object  Key 

- ! - 1 

Data  Fields  | 

1  1 
Component  Facet  | 

•  Facet 

1  1 
•  Facet  term  | 

1  1 

1 _ _ _ L 

|  •  Component  id  | 

i  1 

Table  7.  Facet  SQL  table  content:  This  table  provides  the  object  key 
and  data  fields  for  the  ComponentFacet  table.  The  object 
key  is  to  be  defined  as  a  unique  key  to  enforce  uniqueness. 
Additional  indexing  recommendations  are  given  in  "Additional 
Indexes"  on  page  81. 


C .3.4  SUPPORT  TABLE  CONTENT 


Following  is  a  listing  of  the  relational  tables  to  be  used  in  environment 
support  and  information.  Each  will  include  the  following  items: 

•  Object  keys  which  enforce  uniqueness 

•  Recommendations  for  data  fields 

The  primary  key  of  every  table  will  be  implemented  as  a  unique  index  to 
enforce  uniqueness.  The  fields  which  make  up  the  unique  key  will  be  in 
the  order  listed  in  the  table. 


— 

SQL  Table 

Object  Key 

Data  Fields 

.  .  .  ..  . 

Contract 

i  _  . . . 

•  Contract  id 

.. 

•  Contract  name 

•  Contract  number 

•  Contracting 
agency 

•  Agency  contact 

_ 
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SQL  Table 


Object  Key 


Data  Fields 


Evaluation 


Organization 


Qualification 


User_Subscription 


Verification 


Component  version 
id 


•  Nation  id 


•  Organization  id 


•  Component  version 
id 


User_id 

Component_id 


Component  version 
id 


— 

Person 

— 

•  Person  id  j 

1 

1 

1 

I 

Component_Change 

1 

•  Component  version  | 

id 

! 

Part_Change 

i 

•  Part  version  id  ! 

1 

1 

1 

Problem 

; 

•  Problem  id 

1 

1 

1 

— 

Evaluator_id 
Evaluation_date 
Evaluat ion_report 
Rating 


Name 

Export  Control 
Status 

Name 

Address 

Phone 

US_Entity 


Name 

Employer 

Networkaddress 

Username 

Nationality 

USStatus 


Title 

Changedate 

Changerid 

Change_Report 


Title  | 

Changedate  | 

Changer_id 
Change_Report  ! 

I 


Title 

Reportdate 
Reporter_id 
Resolutiondate 
Respondentid 
Prob lem_report 


Compiled 

Documented 

Tested 

Secure 


Component_vers ion 
Subscript ion_date 


Verif ier_id 
Verif ication_date 
Verif ication_repor 


Table  8.  Support  SQL  table  content:  This  table  provides  the  object 
key  and  data  fields  for  each  SQL  table  in  the  Repository 
design  that  suports  the  environent  support  tools.  Each  ob- 
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ject  key  is  to  be  defined  as  a  unique  key  to  enforce 
uniqueness.  Additional  indexing  recommendations  are  given 
in  "Additional  Indexes"  on  page  81. 


C.3.5  ADDITIONAL  INDEXES 

C.3.5.1  Component  Table 


An  additional  index  will  be  created  for  each  search  field  which  is  added 
to  the  Component  table.  Each  index  will  consist  of  the  search  field  and 
componentid . 


C.3.5. 2  Component  part  Table 


An  additional  index  should  be  created  on  Partversionid  to  support  que¬ 
ries  of  the  type  "Find  all  components  which  use  part...". 


C.3.5. 3  Hierarchy  Table 


An  additional  index  should  be  created  on  Sequence  so  that  the  highest 
number  can  be  found  when  adding  a  new  entry. 


C.3.5. 4  Component  facet  Table 


An  additional  index  should  be  created  on  the  Component_id  to  support 
queries  of  the  form  "Find  the  facets  that  apply  to  component  X  and  find 
their  values". 


C.3.5. 5  Problem  Table 


An  additional  index  should  be  created  on  the  Component_version_id  to 
support  finding  all  problem  reports  for  a  specific  component  version. 


C.3.5. 6  Subscription  Table 


An  additional  index  should  be  created  on  the  Component_id  to  help  find 
all  users  that  are  subscribed  to  a  particular  component. 
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C.3.5.7  ComponentChange  and  PartChange  Tables 

An  additional  index  should  be  created  on  the  Component  version  id  to 
support  finding  all  problem  reports  for  a  specific  component  version. 
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